home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
rbbs_pc
/
msgtos20.zip
/
MSGTOSS.DOC
< prev
next >
Wrap
Text File
|
1992-02-11
|
144KB
|
3,697 lines
MSGTOSS Version 2.0
High-Performance FidoNet Mail Processor for RBBS-PC
Copyright(c) 1989-92 Mike Zakharoff & Warren Muldrow
Mike : FidoNet 1:138/154 Rbbsnet 8:918/10
Warren: FidoNet 1:3617/1 Rbbsnet 8:928/1
ALL RIGHTS RESERVED
T E C H N I C A L M A N U A L
for
MSGTOSS RBBS-PC Mail Processor
Written by Mike Zakharoff, assisted by Tim Jacobs & Craig Gagner
DISCLAIMER
----------
The authors make no claims or warranties with respect to the contents or
accuracy of this publication, or the product it describes, including any
warranties of fitness or merchantability for a particular purpose. Any
stated or expressed warranties are in lieu of all obligations or
liability for any damages, whether special, indirect, or consequential,
arising out of or in connection with the use of this publication or
the product it describes. Furthermore, the right is reserved to make any
changes to this publication without obligation to notify any person
of such changes.
MSGTOSS Version 2.0
L I C E N S E
-------------
MSGTOSS is not a Public Domain program and is not free. MSGTOSS is
copyright(c) 1989,1990,1991,1992 by Mike Zakharoff and Warren Muldrow.
Non-registered users of this program are granted a two week license to
evaluate the program suitability for their requirements. Any usage of
Msgtoss beyond evaluation time period requires registration. Use of non-
registered copies of Msgtoss beyond the original evaluation period is not
wished. You are free to distribute the PUBLICLY AVAILABLE shareware version
of MSGTOSS.
MSGTOSS is SHAREWARE. MSGTOSS was not an easy project, as it took 1000's
of hours to develop and test. The author has written other RBBS utilities
such as MSGRENUM, MAILWAIT, MSGECHO, FIXMSG, all of which were released as
freeware; none of which compares to the complexity of MSGTOSS. Fu-
ture releases of MSGTOSS will depend upon how much support the author re-
ceives. Therefore the author is asking for $25.00 for its use to:
MIKE ZAKHAROFF
18004 22ND ST CT E
SUMNER, WA 98390
Keep in mind that the authors could have easily crippled MSGTOSS with all
sorts of schemes, including disabling the multi-tasking/network support,
requiring a password, annoying "not-registered" lines appended to the tear
line, beg screens, long delays, and other things to pester you to support
the authors. If I were to figure out the amount of hours it took to devel-
op and test this program, it would easily run into 10,000 hours of personal
time that really can't be assigned any value. This was a service to the
RBBS-PC community, and its development will set the stage for RBBS-PC's fu-
ture in the Fidonet community. Cards and letters always welcome!
Registered users will receive a personal registration code (See REGCODE in
MSGCFG.DOC), as much personal support as possible. Non-supporters will
basically be doomed to slither in their own guilt for all eternity.
WARRANTIES
----------
MSGTOSS is guaranteed only to occupy space on your hard drive. Therefore
the use of MSGTOSS is solely at your own risk! MSGTOSS had been beta
tested extensively to eliminate bugs, however due to the limitless pos-
sibilities of system configurations, no warranty is possible. Also,
there are no guarantees that the author will upgrade MSGTOSS.
TRADEMARKS
----------
The following products have been mentioned in this document:
Areafix,Bascom 7.0,Binkleyterm,Confmail,D'Bridge,Desqview,Echodor,
FrontDoor,Lharc,Makearc,Msged,Ommm,Polyxarc,Qmail,Quickbasic 3.0,
RBBC-PC,Rbbsmail,Smlnet,Spaz,Subject & SeaDog
Page - 2
MSGTOSS Version 2.0
Table of Contents
------------------
Page
Mail Tosser Shock ............................................ 5
Purpose....................................................... 5
Non RBBS-PC installations..................................... 5
Features...................................................... 6
SPEED of MSGTOSS........................................... 8
What MSGTOSS won't do (yet)................................ 8
Credits....................................................... 9
Requirements.................................................. 10
MSGTOSS Theory ............................................... 11
TOSS (8 Phases of mail tossing)............................ 12
1 Un-Archiving Mail.................................... 12
2 Packet Identification................................ 13
3 Analyze Pkt Files.................................... 13
Null messages..................................... 14
4 Purge/Expand Message Bases........................... 14
Sysop Messages.................................... 15
Users Messages.................................... 15
Message renumbering............................... 16
Purging whiles users on-line...................... 16
5 Toss messages........................................ 17
File and Record Locking........................... 17
Duplicate Messages................................ 17
Oversized Messages................................ 18
Bad Date or message............................... 18
Unknown Messages.................................. 18
Capturing Messages................................ 18
Right Margin or RBBS messages..................... 19
Security Level of RBBS Messages................... 19
Private RBBS Messages............................. 19
Auto Breaking of Large messages................... 20
Stripping Echomail Control Lines.................. 20
Elastic Message bases............................. 21
Extremely Large Message bases..................... 21
Tossing Display................................... 22
Echomail to SYSOP................................. 22
Feeding Downstream Nodes.......................... 22
Passthru areas.................................... 22
Tossing NETMAIL................................... 23
Killing classes of messages....................... 23
After tossing the *.PKT........................... 23
6 Set Mailwaiting...................................... 24
7 Create MSGTOSS.LOG................................... 24
8 Create Maintenance Batch Files....................... 26
SCAN ...................................................... 27
Private messages........................................... 27
Scanning Philosophy........................................ 27
Mirror scanning............................................ 28
Initialization......................................... 28
Scan RBBS message bases................................ 29
Scan FIDO messages areas............................... 30
Re-scanning to net/nodes............................... 31
Create MSGTOSS.LOG..................................... 31
Page - 3
MSGTOSS Version 2.0
Table of Contents (continued)
------------------------------
Page
What does DOMAIN mean......................................... 32
Networking/Multitasking....................................... 34
Effects of purging whiles users are on-line............ 34
MSGTOSS as a User...................................... 35
INSTALLATION.................................................. 36
Create MSGTOSS directory............................... 36
Copy files to MSGTOSS directory........................ 36
Print & read documentation............................ 37
Modify sample MSGTOSS.CFG.............................. 38
If you are not running RBBS-PC...................... 39
Modify sample MSGTOSS.BBS.............................. 40
Modify default MSGTOSS.BBS Keywords.................... 41
Create MSGTOSS.NOD using MSGNLST.EXE................... 43
Test system setup...................................... 44
Mail tossing test...................................... 47
Mail scanning test..................................... 47
Packing up mail..................................... 47
Command line switches.................................. 48
Batch file modification................................ 49
Packet Unarchiving Info............................. 49
Batch file example.................................. 50
HELP!......................................................... 51
Msgtoss beta testers................................... 51
Msgtoss Beta Distribution Matrix.............................. 52
Errors........................................................ 53
Performance Optimization...................................... 54
Modify RBBSSUB2.BAS to support /MUSER: ....................... 55
Epilog........................................................ 56
INDEX (See MSGIDX.DOC)........................................ <-
Page - 4
MSGTOSS Version 2.0
MAIL TOSSER SHOCK
-----------------
MSGTOSS is a comprehensive, highly configurable program. Because of its
comprehensive nature, the documentation has been split up into four (4)
separate documents. These documents are:
MSGTOSS.DOC - Technical Manual theory of operation & installation
MSGCFG.DOC - Reference Manual for MSGTOSS.CFG (configuration)
MSGBBS.DOC - Reference Manual for MSGTOSS.BBS (areas.bbs)
MSGSWI.DOC - Reference Manual for MSGTOSS command line switches
MSGIDX.DOC - Integrated INDEX of all 4 manuals
The printing out of these manuals should be considered mandatory for the
setup and installation of MSGTOSS. The authors have attempted to provide
as much reference material as possible for MSGTOSS, hopefully avoiding as
many questions as possible for new users. If you are one of those people
who will blindly try to install MSGTOSS without reading the documentation
first, you are in for a surprise.
Jan Maaskant (1:387/255 & 8:931/1) invented the term "mail tosser shock" to
describe the anticipated reaction of new users of MSGTOSS 2.0, especially
after running version 1.3. Reading the provided documentation as much as
possible will help alleviate the symptoms of mail tosser shock.
PURPOSE
-------
MSGTOSS is a high performance tosser/scanner for RBBS systems. It was de-
signed to allow RBBS-PC sysops to import and export Fidonet compatible
Echomail or Netmail into RBBS-PC message bases (or Fido-style sub-direc-
tories), in a fast and efficient manner. In addition, MSGTOSS is highly
zone/domain aware, using its own proprietary nodelist for packet identifi-
cation.
MSGTOSS imports messages directly from Fidonet compatible message packets
(*.PKT files) into RBBS message bases. This direct importing feature
makes tossing of messages extremely fast. It has the capability to
toss mail simultaneously to RBBS message bases, FIDO sub-directories,
passthru to downstream nodes and points, all in one clean sweep. These fea-
tures allows MSGTOSS to be ideal for a HUB situation, as well as a
static node, where all mail can be processed in one sweep.
NON RBBS-PC INSTALLATIONS
-------------------------
Although MSGTOSS is designed exclusively for RBBS, MSGTOSS can also be con-
figured to be run in a non-RBBS system (only support #.MSG messages). For
specific details on this, see INSTALLATION section , "If you are not run-
ning RBBS-PC".
Page - 5
MSGTOSS Version 2.0
FEATURES
--------
Here is a high-level summary of MSGTOSS 2.0 features:
1) - Domain and zone aware.
2) - Tosses and scans from both RBBS and Fido message areas.
3) - Feeds to downstream nodes simultaneously with tossing.
4) - Can be run in a non-RBBS environment (#.MSG format only).
5) - Purges and renumbers RBBS message bases as required.
6) - Maintains RBBS user file Last Message Read pointers.
7) - Maintains its own high water mark to speed up scanning.
8) - Handles selective message and file forwarding.
9) - Handles up to 200 unique nodes in the *.bbs file.
10) - Compatible with AreaFix, QMail, Ommm, etc.
11) - Tosses to RBBS directly from *.PKT files.
12) - Scans directly from RBBS to *.OUT files.
13) - Supports Binkley-Term's outbound area naming for domains.
14) - 25% faster M.DEF & 30% faster Fido tossing from old version.
15) - 200% faster internal purging (over MSGTOSS 1.0)
16) - Improved the MSGTOSS help program. "MSGHELP.EXE <rtn>".
17) - Support to toss from #.MSG format into M.DEF format.
18) - Ability to SCAN individually #.MSG or M.DEF, or both.
19) - Ability to re-scan message bases (for hubbing) to new nodes.
20) - INDIVIDUAL conference configuration of....
a) Whether to re-number message bases
b) When to re-number message bases (threshold setting)
c) Security level of each message base can be different
d) Auto-Breaks large messages into smaller, multiple messages
e) Right margin of messages
f) Whether to support "private" echomail.
g) Whether to strip echo control lines (PATH, SEEN-BY, etc.)
h) Whether to divert messages that contain selected text
i) Whether to provide duplicate checking services
j) Whether to set the mailwaiting bits.
k) Unique Origin lines.
Page - 6
MSGTOSS Version 2.0
l) Whether to prevent purging of user messages for XX days
m) Whether to force messages tossed as "already scanned"
n) Whether to archive purged messages (HISTORY FILE)
21) - NETBIOS, DESQVIEW, PC-NET & 10-NET record/file locking. Allows
safe tossing, scanning & purging while users are on-line.
22) - Supports OPUS-Style (date-written & arrived) date stamps
23) - Supports "capturing" of messages that contain selected text.
24) - MSGTOSS "metacommands". Allows a single command line word to
mean a pre-defined sequence of commands.
25) - GLOBAL maintenance features. Allows MSGTOSS to create a
batch file or execute a command for ALL message bases.
26) - Selectively Kill all netmail or routed mail.
27) - A new "MSGTOSS /TEST" command to validate system set-up.
28) - Allows multiple incoming files directories.
29) - Allows MSGTOSS to become a "user" on the system while tossing.
Anyone entering [W]ho will see MSGTOSS execution status.
30) - Full "point" support, with built-in remapping.
31) - Positively identify the DOMAIN & ZONE of receiving mail packets,
even if PKTS were created by a "zone-dumb" packer.
32) - Allows Intelligent individual MAIL & FILE Routing capabilities,
with ability to "authorize" certain ZONE/NET/NODES (commence
routing) at the same time "lock-out" certain ZONE/NET/NODES (deny
routing).
33) - Ability to identify the sending nodes packer by name.
34) - Ability to "link" multiple AREAS.BBS files.
35) - Ability to import and export, unlimited size messages.
36) - Ability to "mirror scan" messages, where if you have DUAL areas
(both RBBS format and Fido format), MSGTOSS will create a carbon
copy of a message entered in Fido format to RBBS format, and vice
versa.
37) - Supports Qmail-Style "PASSTHRU" areas for HUB support
38) - Does NOT fragment RBBS message bases!
39) - Maintains a "history" file of purged messages.
40) - Option of killing null messages (maintains log file)
41) - Overall more reliable operation, with all 1.3 bugs swatted.
Page - 7
MSGTOSS Version 2.0
SPEED OF MSGTOSS
----------------
This is a relative comparison, but MSGTOSS will toss messages into RBBS
message bases directly from *.PKT file at a rate of approximately 404
messages per minute (no duplicate checking). This is based on an 12 mhz
IBM AT clone with a 300K disk cache. Actual speed will vary considerably.
Users with high performance 386 machines have reported tossing throughput
of over 1000 messages per minute. One off the great assets of MSGTOSS is
the practicality of carrying hundreds of echo's on a single RBBS system,
where speed of importing (prior to MSGTOSS) was prohibitive.
Speed is also affected whether MSGTOSS is feeding (/FEED) downstream nodes
or points. When /TOSS /FEED is active, tossing speed is significantly
slower as MSGTOSS needs to process SEEN-BY lines, where normally it is not
required.
WHAT MSGTOSS WON'T DO (YET)
---------------------------
Currently, MSGTOSS does NOT provide PACKING of mail packets (*.OUT files).
To accomplish this you will need either OMMM (version 1.52+ recom-
mended), QMAIL (just its pack function) or MAKEARC (for file-attach mail-
ers, such as Frontdoor).
Aside from the packer, MSGTOSS is the only utility that would be required
for most node configurations.
MSGTOSS will create *.OUT files after either a scanning run (/SCAN) or
during a tossing run (/TOSS) with the /FEED switch. The packing of these
files (along with scanning of Fido NETMAIL directories) need to accom-
plished via the above mentioned utilities.
NOTE: MSGTOSS does NOT scan NETMAIL directories. The above packers will
accomplish this.
NOTE: It should be noted that complete packing features are in the-
planning/coding phases, and will be implemented in future re-
leases of MSGTOSS.
Page - 8
MSGTOSS Version 2.0
CREDITS
-------
Credit is due to Tom Mack, Jon Martin and Ken Goosans for creating and
maintaining RBBS-PC. RBBS-PC still sets the standard. Credit is also due
to Dan Thomson, Andrew Farmer & Jeff Nonken (authors of SPAZ), who granted
myself permission to distribute SPAZ (un-altered) within the MSGTOSS ar-
chive. Credit is due to Warren Muldrow (co-author of MSGTOSS), who warrants
his own paragraph. All of these folks (in their own way), enhanced RBBS-
PC in some manner or fashion.
ORIGINAL BETA TESTERS
---------------------
To those original MSGTOSS beta testers, who blindingly exposed their pre-
cious RBBS message bases to the early attempts of MSGTOSS; Greg Popovich,
Gray Shockley, Mark Annis, Vaishnava Dasa, Tim Jacobs, Jan Maaskant, Na-
than Barber, Richard Couture & Stan Staten ....thank you. In addition,
these people spent their own $$$ sending me crashed *.PKT files for me to
analyze and create fixes for, calling me voice, and picking up new beta
versions. Apologizes to any of those I have left out by mistake.
WARREN MULDROW
--------------
Although not responsible for the initial design and conception of MSGTOSS,
Warren (who is now a co-author of MSGTOSS) has contributed extensively to
MSGTOSS as it is today. His coding expertise (20+ years experience) has
been proven in many ways by being able to plow through the MSGTOSS source
code (Zakharoff style) and make MAJOR modifications and improvements.
With his innovative spirit, MSGTOSS will continue to evolve in such a man-
ner which will set the standard for not just RBBS-PC systems, but all mail
tossers today. Warren is now the primary focalpoint for MSGTOSS.
Page - 9
MSGTOSS Version 2.0
REQUIREMENTS
------------
MSGTOSS requires a minimum of around 400K for basic static node operation.
For hub work where shelling to a packer is required (along with its shel-
ling to an archive utility), around 520K or so is required.
MSGTOSS was developed on an 12 mhz 286 AT clone, with 640K of ram. It is
written completely in Quickbasic Version 3.0, with ASM routines for se-
lected routines. It is in the process of being written in Bascom 7.0 which
will allow more capabilities.
This document assumes that you have at least the following:
1) An operating RBBS bulletin board
2) Connected to Fidonet or RBBS-NET with a node number
3) Receiving mail packets daily
4) A front end mailer (Binkley, SeaDog, FrontDoor)
It is not in the scope of this document to teach you technical details re-
garding operation and theory of how Fidonet works. This document should
help you get rolling along using the supplied sample files. It is recom-
mended that you obtain documentation to help you understand how the
exporting/importing of mail works. The CONFMAIL documentation provides an
excellent reference on this. A helping hand of another RBBS sysop is the
*best* way to get started.
This document can be VERY confusing. I suggest the first time user of
MSGTOSS skip all the theory and go right to the INSTALLATION Chapter, using
the supplied MSGCFG.DOC, MSGBBS.DOC and MSGSWI.DOC constantly during the
setup.
MSGTOSS has its own dedicated echo called "RBBS_MSGTOSS", available on the
Rbbs-Net backbone. Another source could be the "RBBS-PC" echo, available
on both the Rbbs-Net and Fidonet backbones. The authors are available for
consultation, although we prefer you thoroughly exhaust all sources of in-
formation first. The reason for the extensive documentation is to avoid
basic questions, easily answered on the first few pages of documentation.
Most of the beta testers will be happy to provide assistance, or maybe a
call from a local RBBS SYSOP may guide you in the right direction to re-
ceiving the right information.
Page - 10
MSGTOSS Version 2.0
MSGTOSS THEORY
--------------
MSGTOSS is a comprehensive mail processor for RBBS systems. As a conse-
quence, there are currently 42 command line switches or options, over 46
MSGTOSS.CFG configuration parameters and 19 MSGTOSS.BBS keywords that all
interrelate with one another. To see how this all fits together, you will
need to read the corresponding reference manual for each area.
MSGSWI.DOC contains reference material for all MSGTOSS command line
switches. MSGCFG.DOC contains reference material for MSGTOSS parameters
associated with MSGTOSS.CFG (configuration file). And MSGBBS.DOC is a
reference manual for all if the MSGTOSS keywords used in the MSGTOSS.BBS
file. Each of these aspects should be understood prior to attempting to
configure MSGTOSS.
This tremendous number of interrelated system configuration items demon-
strates the amount of flexibility built into MSGTOSS. I claim MSGTOSS
to be the most advanced Fidonet tosser in the world (and most certainly
for RBBS). You should be able to utilize its power to fully automate your
echomail process.
In addition to processing mail, it has other non-tossing utilities built
-in. Because of this, there are TEN MAJOR command line switches, which
tell MSGTOSS what major operation is being requested. When a major command
line switch is issued, any other switches not related to the major opera-
tion are simply ignored. You cannot issue TWO major command line
switches simultaneously. For explanation and the use of the switches use
the reference manual MSGSWI.DOC.
SYNTAX: MSGTOSS [/SWITCH] [/OPTIONS...]
The TEN major command line switches...
1) Toss RBBS, FIDO & NETMAIL messages -------> /TOSS
2) Scan (export) new locally entered mail ---> /SCAN
3) SIZE message bases to preset RECS:xxx ----> /SIZE
4) Reset users Mailwaiting Bit (all msgs) ---> /MWRST
5) Report on message base statistics --------> /STAT
6) Test MsgToss Setup Configuration ---------> /TEST
7) Wait for users, create MSGWAIT.BAT file --> /WAIT
8) Globally execute xxx for all msg bases ---> /GLOB:xxx
9) Recompile the node list (MSGTOSS.NOD) ----> /NLST
10) Execute MSGEID.EXE - EID Datamase Maint --> /EID
12) MSGTOSS.CMD metacommands - (no slashes) --> xxx
12) MSGTOSS.BBS Tossing Configuring Keywords -> xxx
13) MSGTOSS DOS ErrorLevel Codes -------------> Errorlevels
NOTE: Executing MSGTOSS<rtn> at the DOS prompt will produce a similar dis-
play. You can then enter the number of the major command line switch,
then all related switches are displayed along with a description and
purpose.
Page - 11
MSGTOSS Version 2.0
TOSS
----
The /TOSS command switch is for tossing Fidonet compatible message packets
(*.PKT) into your RBBS message bases (M.DEF) or into a DOS directory (as
a FIDO #.MSG). The /TOSS option has 28 switches. TOSS signals MSGTOSS to
start a carefully planned sequence, used more often than any other switch.
There are 8 phases to the TOSSING of messages:
1) Un-Pack mail packets
2) Identify domain/zone/net/node of *.PKT files
3) Analyze *.PKT files
4) Purge/expand RBBS message bases as required
5) Toss messages (RBBS message bases or Fido)
6) Set the mailwaiting bit for conference users
7) Create a MSGTOSS.LOG file for message base activity
8) Create miscellaneous BAT/CMD/CTL files for other maintenance.
PHASES OF TOSSING MAIL
----------------------
UN-ARCH MAIL PACKETS
--------------------
Incoming mail packets are received by your respective front-end mailer as
either archived (*.MO*, *.TU*, etc.) or as a regular *.PKT file.
SPAZ (supplied within the MSGTOSS distribution archive) will detect what
type of archive it is and unpack it into one of the directories specified
by the multiple FILES-------> entries. You will have to provide the
correct SPAZ command (or other unpacker) in your batch file. Its syntax
is:
SPAZ [In Directory] [Out Directory]
NOTE: For optimum capability, it is recommended that the FIRST FILES----->
entry in your MSGTOSS.CFG be the incoming files directory. This is
the directory where all files (via your front-end mail) go first. The
reason for this is that during FILE ROUTING (explained further)
MSGTOSS will assume the first FILES-------> entry as where routed
files go.
NOTE: It should also be noted that you can substitute SPAZ or any other
type of un-packing utility (such as GUS or POLYXARC) if you don't
want to use SPAZ. The only critical thing to remember is that MSGTOSS
will only look in your FILES--------> directories for *.PKTS, so you
have to make sure that after executing the un-packer, the *.PKTS are
found my MSGTOSS.
You may have several different directories your mail is coming into (Mul-
ti-Node Systems). Using the FILES-------> in the MSGTOSS.CFG file, you can
specify where these directories are.
Page - 12
MSGTOSS Version 2.0
PACKET IDENTIFICATION
---------------------
MSGTOSS goes through extensive packet identification routines that
reliably identify the source DOMAIN, ZONE, NET & NODE and PACKER of the
PKT file. This is accomplished by a proprietary nodelist that
MSGTOSS creates during your weekly nodelist processing batch file.
Whenever the source of the PKT is unknown or MSGTOSS doesn't have
enough information, MSGTOSS will look up the information regarding the PKT
in its own nodelist. The name of this nodelist is "MSGTOSS.NOD" and is
created automatically when you execute MSGNLST.EXE or MSGTOSS /NLST. For
more information, see INSTALLATION section and MSGSWI.DOC.
The reason for having a proprietary nodelist is to ensure compatibility be-
tween different mailer systems, and to ensure the authors of MSGTOSS have
control over the format required.
In addition, MSGTOSS looks up the name of the packer (i.e. Qmail,
Rbbsmail, Confmail) in accordance with the product code that is present in
all legitimate packers. It gets this information in a file called
"MSGTOSS.PCD" (Product Code). Using this combination of nodelist and prod-
uct code files, MSGTOSS is able to determine many things. Lets take
the packet: 50455040.PKT. Msgtoss looks at the header information and sees
this.
NOTE: Frequently, the Software Distribution System (SDS) distributes a file
called "FTSCPROD.xxx", which is an updated list of MSGTOSS.PCD. When
you obtain an updated product code listing, rename it, keeping
MSGTOSS.PCD up-to-date.
50455040.PKT To:@1:387/255@fidonet Fm:@1:387/5@fidonet 1A D'Bridge 1.0
It includes the original domain & zone, destination domain & zone, as well
as the source packer. All of this information is logged in the
MSGTOSS.LOG file. If MSGTOSS is truly confused regarding the source/desti-
nation of a PKT file, MSGTOSS will default to the FIRST (primary)
NODE-------> entry (in the CFG file) regarding DOMAIN & ZONE.
ANALYZE PKT FILES
-----------------
MSGTOSS will then read the contents of each *.PKT and create a correspond-
ing *.IDX file for each packet. If the packet is 11112222.PKT it
will create a file called 11112222.IDX which contains information about
each message in each of the packets. This occurring should be transpar-
ent to the user, as MSGTOSS will create and delete these *.IDX files as
required. This analysis phase is critical, as MSGTOSS needs to know ex-
actly how much space is required to import new messages. If MSGTOSS
finds an existing *.IDX file, it will re-analyze it, vice the *.PKT.
NOTE: MSGTOSS will create these *.IDX files in the same directory where
its corresponding *.PKT file is located. For those fortunate to have
huge RAM disks, make sure the maximum directory entries can han-
dle all these *.IDX files being created. For instance, it is not
uncommon for a hub to process 150 *.PKT files at a time. MSGTOSS will
Page - 13
MSGTOSS Version 2.0
create a *.IDX file for each of these, so 300 files will eventually
end up after analysis. If your directory maximum is 256... problems.
During the analyzing phase, MSGTOSS also determines what NET/NODES
that are listed in your MSGTOSS.BBS file haven't seen the message, and
creates a IDX entry so later (during the toss) MSGTOSS already knows
who needs to be sent the message, without loading the entire message
into memory. Because of this, MSGTOSS has no theoretical limit
on message size. This is significant, as most other mail tossers in the
Fidonet community have substantial limits (most are around 16K) on the
message sizes that it can handle.
NULL MESSAGES
-------------
If a message is determined to contain only a valid header, and no text
within the body of the message, MSGTOSS will selectively kill the message.
Messages like this turn out to be a nuisance, as some mailers send null fi-
le-attach messages to send regular *.PKT files. MSGTOSS will detect a null
message, kill it, and log its occurance into a file called MSGTOSS.NUL.
This is selected via the KILLNULL---> parameter. Setting to 'Y' will en-
able this feature.
PURGE/EXPAND MESSAGE BASES
--------------------------
After the analyzing phase, MSGTOSS then knows how much space will be
required to successfully import the messages contained in each of the
*.PKT files received. It will then either PURGE the message bases or
EXPAND (or both) prior to tossing. If you specified the /PREP switch (pre-
purge), MSGTOSS will first load all of the USERS in a particular conference
in memory (see NOTE:), and will commence to purge non-user messages. This
is accomplished via a 'pack-in-place' method, where the messages flagged
to keep will be 'shuffled' to the beginning of the RBBS message base,
as others are being deleted. This pack-in-place method avoids fragmenta-
tion of the message bases. Only if a message base is expanded will frag-
mentation occur.
NOTE: The BBS keyword "USRH:1" directs MSGTOSS whether to load all of the
users into memory prior to purging. For very large message bases with
alot of users, the purging speed can be dramatically increased by us-
ing the "USR:0" BBS keyword, as hashing users will no take place.
However, loading the users have alot of benefits (read on).
NOTE: MSGTOSS will purge ONLY ENOUGH messages for successful importation.
Therefore, if only 2-3 messages are received in a particular confer-
ence, then roughly the same amount will be purged (if there isn't en-
ough space to begin with).
NOTE: MSGTOSS can handle roughly 1500 users in memory at any one time. If
MSGTOSS detects that it is running out of memory as users are being
loaded, it will stop loading in memory and page the remaining
users to disk. This causes the purging to be slower (but more com-
plete). For optimum operation, try to keep the sizes of your
conference users under 1500 or use the USRH:0 BBS keyword where
Page - 14
MSGTOSS Version 2.0
appropriate.
Using the "USRH:1" BBS keyword will prevent messages from being
purged before the sysop or conference users have had a chance to
read them. MSGTOSS will make sure these messages are not purged,
with the following exceptions.
NOTE: If using the "HIST:1" BBS keyword, whenever a message is purged,
MSGTOSS will export, in text format, the message into a *.HIS file.
If the message base being purged is RBBSM.DEF, and HIST:1 is true,
MSGTOSS will export all purged messages into a file called RBBSM.HIS.
SYSOP MESSAGES
--------------
Incomming messages will always be checked to see if they match the
multiple SYSNAMES----> entries, regardless if the "USRH:0" BBS keyword
(don't hash users) is active (Fidonet is mostly for SYSOPS, right?).
For SYSOP messages (messages where to/from = SYSNAMES---->) during a
purging operation, the following rules apply:
1) If the message is already killed, purge it.
2) If the message has already been read (and the DELREADSYS
is set to 'YES', purge it.
3) If the message is TO the SYSOP, and the message is OLDER
than XX days as specified in the DAYSTOSYS parameter, then
purge it.
4) If the message is FROM the SYSOP, and the message is
OLDER than XX days as specified in the DAYSFRSYS parameter,
then purge it.
5) Otherwise leave it alone!
USER MESSAGES
-------------
Same as above for the SYSOP, except:
1) The BBS keyword "USR:1" must be active (means MSGTOSS
will load all conference users into memory).
2) The associated CFG parameters are DELREADUSR, DAYSTOUSR &
DAYSFRUSR, respectively.
NOTE: If you decide to NOT load the users into memory via BBS keyword
"USRH:0", then users messages may be deleted before the user has had
a chance to read them. However, if the user is a regular caller, and
you keep your message bases large, a newly entered message may take
some time to recycle through multiple purging sessions, so the user
may have a chance to read them. If you keep small message bases
(mine are only 900 records) then definitely use the "USRH:1" BBS key-
word.
USER/SYSOP SUMMARY
Page - 15
MSGTOSS Version 2.0
------------------
This 'smart purging' is an important concept for MSGTOSS, as messages
left TO/FROM the users (and the sysop) of the conference WILL NOT be
deleted until they are either killed or their time limit has run out
(as specified by the various DAYSTO???/DAYSFR??? parameters).
If after the 'pack-in-place' purging there is still not enough space
to import all of those messages, MSGTOSS will EXPAND the message base
as it sees fit to allow successful importation. MSGTOSS expanding the
message base is not a big deal. In fact it sometimes necessary when,
for instance, your HUB has been shut down for a couple of days, and
you are suddenly flooded with messages. Because MSGTOSS doesn't
think twice about expanding when it needs it, built-in 'smart siz-
ing' code is built into MSGTOSS to easily maintain tight control on
the sizes of the message bases. In fact, these built-in utilities are
superior to RBBS-PC CONFIG utility. After MSGTOSS is initially set up
properly, adding a simple line to your daily maintenance batch file
"MSGTOSS /SIZE" will chop the message bases back down to a predeter-
mined level in one swipe. So again, if MSGTOSS expands a message
base, that one command will cleanly and easily return it back to its
original size, using smart purging techniques. Remember, MSGTOSS
will ONLY expand a message base if it absolutely needs to. If after
the built-in purging there's STILL not enough messages, then and
only then will it expand message bases.
If you specified the /PREX (pre-expand) switch, then MSGTOSS will
simply EXPAND the message base as it sees fit and continue on. At a
later time (say at a night event) to can CHOP the message bases back
down to their original size by issuing the /SIZE or /SIZE-UP
switches. If you add the switch /FIX to the command line, then
MSGTOSS will automatically SHELL to FIXMSG if it detects a corrupt
message file while doing the purge. It will execute FIXMSG twice, and
if it still fails to correct the problem MSGTOSS will simply abort.
If you use the switch /FIXC switch (instead), MSGTOSS will do the
same as above, but will copy the BLANK message base (model) as speci-
fied by the BLANKMSG---> parameter over the corrupt message base,
and rename it to *.BAD. This prevents MSGTOSS from aborting due to a
corrupt message base.
MESSAGE RENUMBERING
-------------------
MSGTOSS will renumber the message bases AS they are being purged. The
renumbering will be in accordance with the "RNST:xx" and "RNIF:xx" BBS
keywords. The "RNST:xx" tell MSGTOSS what number the newly renumbered
messages should start with. IE:You like all message bases to start
with 1000+, you enter "RNST:1000" as a BBS keyword. The "RNIF:xx" BBS
keyword will tell MSGTOSS to renumber, but ONLY IF the last message
(prior to a purge) is greater than/equal to "RNIF:xxx".
In addition, MSGTOSS will (upon finishing purging) reset the
"last message read" flag (in the associated USER file) to the
new/next closest message number, so last-read flags are not lost.
PURGING WHILE USERS ARE ON-LINE
Page - 16
MSGTOSS Version 2.0
-------------------------------
MSGTOSS adheres to standard file/record locking protocols used by
RBBS-PC when tossing/purging/sizing message bases. For a more de-
tailed description of this, and its effect on users who happen to be
on-line, see section on MULTITASKING/NETWORK SUPPORT.
TOSSING INTO RBBS & FIDO FORMAT
-------------------------------
After the RBBS message bases were prepared for the new message (purged,
expanded, etc.), they are now ready to receive new messages. MSGTOSS will
toss each of the messages contained in *.PKT files to either an RBBS mes-
sage file, a sub-directory in Fido Message form, a *.OUT file for either
PASSTHRU areas for downstream nodes, or all three.
FILE & RECORD LOCKING
---------------------
MSGTOSS adheres to standard file/record locking protocols used by
RBBS-PC when tossing/purging/sizing message bases. To use this fea-
ture, use the /LOCK command line switch. For a more detailed de-
scription of this feature, see the section in the MSGSWI.DOC. Also
see /MUSER:x command line switch, and MULTITASKING/NETWORK SUPPORT.
DUPLICATE MESSAGES
------------------
MSGTOSS handles duplicate checking alot different than other mail
processors. It creates and maintains a duplicate database file
called MSGTOSS.EID. This file is a random access file that contains
all of the EID:, MSGID:, and MSGTOSS generated ID codes for the last
XXXX messages, as specified by your DUPSIZE parameter, for all of
your conferences. The reason for the single database-type format is
simple, opening and closing files takes time, and having a sin-
gle file that is opened all the time will make it faster.
The CDUP:x keyword allows individual conference configuration as to
whether you want DUP checking to apply for a particular conferences.
NOTE: The supplied MSGTOSS utility (MSGEID.EXE) provides a means of
modifying and maintaining the MSGTOSS.EID database.
NOTE: When using the work directory switch (/WDIR), MSGTOSS will auto-
matically copy the MSGTOSS.EID database file to the RAM disk (as
specified by the WORKDIR---> parameter) prior tossing for faster
operation. After tossing, MSGTOSS will automatically copy it
back to preserve its data.
MSGTOSS will check for duplicates during the tossing phase (must
specify the CDUP:1 keyword), and if one is encountered, it will simply
ignore the message and display an informational line of the duplicate
while tossing. If you specified the /DLOG (Maintain Dup Log File) then
when a duplicate is encountered MSGTOSS will append the date, pkt, msg
number, area, net/node of originating system and the message header
into a file called MSGTOSS.DUP.
Page - 17
MSGTOSS Version 2.0
NOTE: The areas NETMAIL, UNKNOWN, ROUTETHRU & MSGCAPTURE are
exempt from dup checking.
OVERSIZED MESSAGES
------------------
There is no SIZE LIMIT of an imported message. MSGTOSS will import
without problems an entire BOOK if asked to. During the toss,
however, messages that are known to be over-sized (over the limit
specified by the KILLOVER parameter) will be simply ignored. This
prevents your message bases from being un-duly large due to a few
large messages. This applies ONLY to RBBS message areas. If tossing
to a Fido area, then the whole message will be tossed.
BAD DATE, MESSAGE HEADER
------------------------
Messages that are found to contain bad dates will be logged into the
MSGTOSS.ERR file, but will be tossed anyway. MSGTOSS does a good
job interpreting the various forms of dates that show up in a *.PKT
file, however, some it will not handle (like typos). For these
messages, MSGTOSS will convert the date to 'Todays Date/Time' for
RBBS message bases. If tossing as a Fido message, it will leave the
date intact (as it was).
For messages that have flaky message headers (grudged, etc.) MSGTOSS
will just ignore the message and log it into the MSGTOSS.ERR file,
along with the flaky header.
MSGTOSS does not bother tossing 'bad' messages, this just adds more
work for the sysop. Instead, MSGTOSS will log the bad message into the
MSGTOSS.ERR file, and it will tell you what went wrong.
UNKNOWN MESSAGES
----------------
Messages that are found to contain an unknown AREA tag will be tossed
into the Fido directory or RBBS message bases that is specified for
the UNKNOWN area. The UNKNOWN area is required, but if you specify
the '/KUNK' (Kill Unknown) switch they will be ignored (deleted).
Messages marked as UNKNOWN that are tossed will be tossed along with
their original AREA:xxxx tag and are exempt from dup and size check-
ing (even with the CDUP:1 keyword).
NOTE: Assuming that a previously UNKNOWN message becomes KNOWN, and
the area UNKNOWN is a Fido-Style area, you can toss these mes-
sages into RBBS format via the /TUNK (toss unknown) switch. The
most likely reason for a message to be unknown is either you
forgot to put the new AREA:TAG in the MSGTOSS.BBS file or an im-
proper link between node and host.
The /TUNK switch is meant to be used only when necessary. Placing it
permanently on the /TOSS command line will greatly slow down the toss-
ing process.
CAPTURING MESSAGES
Page - 18
MSGTOSS Version 2.0
------------------
MSGTOSS provides sysops with the ability to CENSOR messages in an au-
tomated fashion. This is accomplished via the BBS keyword CAPT:1 in
conjunction with CAPTURE-----> configuration entries. When you enter
a 'colorful metaphor' in the CAPTURE CFG entry(s), and you config-
ure a conference as a captured conference (via CAPT:1) then MSGTOSS
will monitor the messages PRIOR to importing and divert them into
a special area called 'MSGCAPTURE'. It is most useful that this area
be a Fido Style area. If you specify an RBBS message base as the
captured conference, then moving them later is very difficult.
Assuming MSGCAPTURE is a Fido area, you can then look at them an
after censorship can then toss these messages in their proper
conference via the '/TCAP' (toss capture) command line switch. This
works in exactly the same way as /TUNK (toss unknown) switch.
NOTE: When using the /FEED switch, captured messages will still be
exported to downstream nodes. A captured message is strictly LO-
CAL in nature.
Why have this feature? If you don't want a bunch a swear words on
your BBS is one application. Another may be that you belong to 50
echoes, and you want all of YOUR personal messages captured so you
can read/respond prior to importing. Is the use of this feature
ethical? Its up to you. Obviously abuses can occur via this fea-
ture.
NOTE: Never CENSOR other peoples mail! If you are a hub and use this
feature (inappropriately) you will suffer the consequences.
That is NOT ethical.
RIGHT MARGIN OF RBBS MESSAGES
-----------------------------
RBBS messages are normally formatted to a right margin of 72. If you
set your MRGN: keyword in your MSGTOSS.BBS file to say MRGN:77, then
the imported messages may look more proper, as most BBS systems allow
right margins of 79. Editing of these messages may be more diffi-
cult, because RBBS expects messages to be 72.
SECURITY LEVEL OF RBBS MESSAGES
-------------------------------
RBBS has the capability of setting a security level for the actual
CONFERENCE, and for the messages within. The ESEC:xxx BBS keyword
configures what the security level of tossed messages are for a par-
ticular conference. For instance, setting ESEC:5 as a BBS keyword
will set all messages for which the BBS keyword applies to a security
level of 5.
NOTE: This is a very important BBS keyword! If you set ESEC:100 and
all users (and the SYSOP) have security levels below 10 then
even the SYSOP won't be able to read messages.
PRIVATE RBBS MESSAGES
---------------------
Page - 19
MSGTOSS Version 2.0
RBBS-PC allows private messages to be entered in echo areas. This is
a good feature, as some echoes are meant for that. However, some sy-
sops prefer all incoming echomail to be PUBLIC instead of PRIVATE.
The BBS keyword PRIV:x configures whether the private attribute is
honored for messages imported/exported. For instance, you set
PRIV:1 (private allowed) and a private message arrives for a user;
MSGTOSS will set the message to be private ("*" before the message
number), otherwise, it will be converted to public. If a private is
entered then MSGTOSS will set the private attribute when exporting
the message to a *.OUT file.
PRIV:1 - Private message arrives, set as PRIVATE
Private message entered, exported as PRIVATE
PRIV:0 - Private message arrives, set as PUBLIC
Private message entered, NOT-exported
NOTE: For more information on this See /SCAN section.
AUTO-BREAKING RBBS MESSAGES
---------------------------
RBBS-PC has a limitation of 150 lines that will be displayed to a us-
er, even though the message is much longer. For very large mes-
sages, its almost impossible to read the entire message, much less
respond to it. The BBS keyword MAXL:xxx allows you to tell MSGTOSS
to auto-break a message into multiple messages. For instance, if you
set MAXL:100, then whenever MSGTOSS encounters a message that is
longer than 100 lines, it will stop importing, create a new message
with the same header, and finish the message. As part of this pro-
cess, MSGTOSS will append the following to the end and beginning of
these messages, respectively:
MsgToss (Continued on NEXT message)
MsgToss (Continued from LAST message)
NOTE: If you decide to use RBBSMAIL (or any other type of RBBS mail
processor) vice MSGTOSS to re-scan message bases (for HUB work)
then set MAXL: very high (32000), as you don't want MSGTOSS to
auto-break messages. If you exclusively use MSGTOSS to
scan/re-scan (as you should), then no problem, as MSGTOSS will
attempt to re-create the original message during a re-scan.
STRIPPING ECHOMAIL CONTROL LINES IN RBBS
----------------------------------------
Echomail contains alot "control lines" which are normally not dis-
played to the user. These lines such as "SEEN-BY:", "PATH:" and "EID:"
lines can be stripped out of the RBBS messages by using the "SECL:1"
BBS keyword in conjunction with the "FMAS:1" keyword.
The type of lines to be stripped are configured via the ,"SECL------
-->" parameter entries in the MSGTOSS.CFG file. These entries allow
the sysop to decide exactly what lines are to be ignored and up to 20
"SECL-------->" entries are possible.
This allows as many messages to be imported into the RBBS message
Page - 20
MSGTOSS Version 2.0
base(s) in the allocated space defined. See MSGBBS.DOC and MSGCFG.DOC
for more detail.
ELASTIC MESSAGE BASES
---------------------
MSGTOSS by default is always checking that the "max message" value
that is present in the message base, "checkpoint record". This is al-
ways in accordance with RBBS-PC standards (can be modified by the
MSGMULT parameter). If you elect to use the elastic message bases
first introduced in RBBS 17-2 you simply set the "ELASTIC---->" pa-
rameter to "YES". Basically all this does is whenever MSGTOSS tries
to set the "max messages" value, it will set it to the value of the
"RBBS-MAX---->" parameter (currently 999).
NOTE: For proper operation of the ELASTIC message bases, the MAINT%LO
and MAINT%HI parameters should be set to a value of 100 each.
This tells MSGTOSS during purging, sizing and tossing to leave
as little amount of slack space at the end of the message bases
as possible (100 percent full at all times). RBBS will expand
the message bases as users enter new messages.
EXTREMELY LARGE MESSAGE BASES
-----------------------------
If you keep extremely large message bases (over 4000 records) it is
possible for your message bases to exceed the (current) RBBS-PC maxi-
mum of 999 messages per message base.
Certain precautions are built into the MSGTOSS purging code to prevent
this, such as the SLAK:xx keyword and pre-counting (further ex-
plained).
NOTE: The maximum of 999 may soon be increased, this is why the
"RBBSMAX---->" parameter is present in the MSGTOSS.CFG file. The
default entry is 999, which reflects the "current" RBBS-PC maxi-
mum. In the event the maximum is raised (future releases of
RBBS-PC) the MSGTOSS "RBBS-MAX--->" parameter will have to be
adjusted. Also, it is possible to modify the RBBS code to in-
crease the built-in 999 message limitation. The RBBS-MAX parame-
ter allows you to do this safely.
The formula used to trigger a pre-count is (RBBS-MAX * 4), where if
the number of records exceed this amount, that will cause a pre-count
of the messages prior to tossing. Example:
RBBS-MAX = 999, "precount" = (999 * 4), Trigger = 3996 recs
Therefore MSGTOSS will do a "pre-count" of the messages prior to
tossing. This "pre-count" is automatic and is triggered only when
MSGTOSS senses a (RBBS-MAX * 4) record (or greater) message base.
In the event of an "overflow", MSGTOSS will not allow any more messag-
es to be imported into the message base, but will allow other message
bases to be processed as normal. After the *.PKT is tossed normally,
MSGTOSS will rename the *.PKT to *.OFL (for overflow) and log the
occurrence of the overflow into the MSGTOSS.LOG and MSGTOSS.ERR
Page - 21
MSGTOSS Version 2.0
files. The sysop can then elect to fix the overflow problem, or sim-
ply delete the *.OFL file. Tossing of selected echoes are possible
via the /AREA: command line switch(es).
NOTE: Again, the possibility of an overflow is unlikely with
MSGTOSS 2.0, not so with earlier versions.
TOSSING DISPLAY
---------------
During the tossing phase, alot of tossing activity is displayed to the
user. If you would like to suppress this, simply add the '/DDA' switch
to the MSGTOSS command line. This will also result in faster process-
ing of messages. However, any informational warning (like duplicate,
oversized, bad date, etc.) will still be displayed.
ECHOMAIL MESSAGES ADDRESSED TO 'SYSOP'
--------------------------------------
Although its irritating, alot of Fidonet mail processors happily allow
messages entered TO:SYSOP to be exported into public echomail areas,
thus when these messages arrive to your system, RBBS-PC notifies you
that YOU have mail-waiting. Whenever MSGTOSS sees an echomail message
that addressed to 'SYSOP', MSGTOSS will change the addressee to 'SYS-
TEM OPERATOR'.
NOTE: During a re-scan of a message base (HUB situation), MSGTOSS will
convert these names back to 'SYSOP' to equally irritate those
which you are re-scanning to.
FEEDING DOWNSTREAM NODES
------------------------
If you are a HUB, or you support POINTS, you can simultaneously create
*.OUT files addressed to your nodes/points by using the /FEED switch
on your /TOSS command line. Using this switch will automatically feed
your nodes & points as MSGTOSS is tossing to your RBBS message bases
(M.DEF) or #.MSG format. Note that the use of the switch requires
more processing (SEEN-BY lines, etc.), so it will increase process-
ing time slightly. For more information, see MSGSWI.DOC reference
guide. Also see 'Scanning Philosophy', as it relates to /FEED.
PASSTHRU AREAS (For HUBs)
--------------
MSGTOSS supports Qmail-Style passthru areas. These are configured as
having a "#" (pound sign) as the FIRST character in the MSGTOSS.BBS
file, followed by the area name. For instance, a passthru area for
the COMM area would be entered as follows:
#(Optional Path) COMM 343/300 56 67 89
The optional path is not required by MSGTOSS, but some mail processors
(such as Qmail or AreaFix) get upset when a path is not entered there.
In order to activate this feature, you must use the /FEED switch. As
MSGTOSS is tossing to your RBBS message bases and local Fido style
Page - 22
MSGTOSS Version 2.0
areas, it will also toss the same messages to your down-stream nodes.
This type of area indicates that you are simply 'passing' the area to
other nodes, and are not keeping it locally. It is most likely you
will not be doing this unless you are a Hub of some sorts.
TOSSING NETMAIL
---------------
Netmail messages are usually tossed into a Fido style directory, where
either a local editor (such as MSGED) or netmail door (such as ECHODOR
or SMLNET) can be used to respond. MSGTOSS provides full point-re-
mapping, file/mail forwarding capabilities (with security envelope).
KILLING (IGNORING) CLASSES OF MESSAGES
--------------------------------------
MSGTOSS provides three specialized command line switches that are de-
signed to assist those sysops who which to use MSGTOSS in conjunction
with another mail processor (such as Qmail). MSGTOSS allows (via the
/KNET, /KUNK & /KRTE comm and line switches) the sysop to determine
whether he/she wants MSGTOSS to ignore NETMAIL (/KNET), UNKNOWN
(/KUNK) and ROUTETHRU (/KRTE).
NOTE: MSGTOSS is capable of tossing all of the above classes of mes-
sages, and can provide exceptional mail/file routing capabili-
ties. These switches are extremely specialized and should only
be used with full understanding of what they do.
The KILLNULL parameter determines whether MSGTOSS will kill (ignore)
null messages. These messages contain no text body, usually used for
sending files or *.PKTs from file-attach type mailers. If KILLNULL is
set to 'Y' (yes), MSGTOSS will kill the null message, and log its oc-
curance to a file called MSGTOSS.NUL.
AFTER TOSSING THE PACKET
------------------------
After tossing the *.PKT, MSGTOSS will automatically delete the respec-
tive *.PKT and *.IDX file and continue on to the next *.PKT file.
NOTE: If you wish to keep the *.PKT files for further processing, sim-
ply use the "/DKP" switch. This will delete the *.IDX file but
will leave the *.PKT file available for other processors (like
for HUB work).
Page - 23
MSGTOSS Version 2.0
SET MAILWAITING BIT
-------------------
After successful tossing of the messages, MSGTOSS will then set the 'mail-
waiting bit' for all RBBS conferences which are configured to set the mail-
waiting bits (via MWST:x keyword) and which received mail. This allows us-
ers to be notified when they log-on the system whether they have mail
waiting to be read in each of the conferences. During initializing,
MSGTOSS remembered what the first message was before it started tossing,
therefore if you use the MWST:1 keyword, it will ONLY set the bit for the
brand-new messages.
If you want to reset all mailwaiting bits for all conferences, you can use
the /MWRST (mailwaiting reset) command line switch. See MSGSWI.DOC for
more information on this.
For messages that are addressed to the SYSOP or the SYSOP's common name
(IE:Mike Zakharoff), the TO: field will be changed to 'SYSOP' so when you
log-on as the sysop, proper notification will be made.
The SYSALIAS parameter (located in MSGTOSS.CFG) tells MSGTOSS which user
name is considered the SYSOP. This should be the same name as was entered
in CONFIG for the secret remote logon, and for 'LOCAL' logon (ESC switch).
Any messages that match those as specified by the various SYSNAME(s) will
cause the mailwaiting bit for the SYSALIAS user to be set, and cause the
TO: field to be changed to the text 'SYSOP', if 'SYSOP' is not already
part of the TO: field.
NOTE: MSGTOSS requires that all conferences contain the SYSALIAS user.
During the mailwaiting phase, it will check this, and if not present,
will annoy you until you add it. It wants to always make sure it
knows what mailwaiting bit to set for SYSOP.
NOTE: You can obtain faster purging, mailwaiting and sizing by con-
figuring MSGTOSS to use a work directory. This is set via the WORK-
DIR---> parameter. To initiate the work directory specify /WDIR
on the command line while executing MSGTOSS. If a RAM disk,
MSGTOSS will first copy the message base to the RAM disk (if en-
ough room exists) and will purge the message base as required.
After purging, MSGTOSS will then copy it back automatically.
In addition, if paging excess users to the disk is required,
MSGTOSS will use the work directory for faster operation. If you put
ANYTHING in this spot it must at minimum be a valid drive.
CREATE LOG FILE
---------------
MSGTOSS keeps a useful log of the activity after each mail event. The di-
rectory of where this log file is created is specified by the LOGDIR----->
parameter. Here is an example of the log:
MsgToss 2.0 01/03/92 - Report Date: 01-01-1992 00:27:06
9BA308A0.PKT To:@1:343/36@fidonet Fm:@1:343/300@fidonet 29 QMail 1.0
9BA61FB7.PKT To:@1:343/36@fidonet Fm:@1:343/300@fidonet 29 QMail 1.0 NET
Page - 24
MSGTOSS Version 2.0
9BA80FE1.PKT To:@1:343/36@fidonet Fm:@1:343/300@fidonet 29 QMail 1.0
9BC7D716.PKT To:@1:343/36@fidonet Fm:@1:343/300@fidonet 29 QMail 1.0
PURG&RNUM - GENEALM.DEF Purged: 141 Kept: 0 Users: 5 Set LMR
EXPANDED - GENEALM.DEF from 1008 to 1361
PURG&RNUM - COMMM.DEF Purged: 73 Kept: 26 Users: 14 Set LMR
PURG&RNUM - CLIPPERM.DEF Purged: 15 Kept: 79 Users: 5 Set LMR
PURG&RNUM - CONSULTM.DEF Purged: 4 Kept: 76 Users: 2 Set LMR
PURG&RNUM - COOKINGM.DEF Purged: 98 Kept: 0 Users: 3 Set LMR
EXPANDED - COOKINGM.DEF from 800 to 850
PURG&RNUM - C_PRGMM.DEF Purged: 40 Kept: 43 Users: 6 Set LMR
PURG&RNUM - OS2M.DEF Purged: 25 Kept: 76 Users: 2 Set LMR
PURG&RNUM - QUIKBASM.DEF Purged: 10 Kept: 96 Users: 7 Set LMR
PURG&RNUM - SCIENCEM.DEF Purged: 19 Kept: 50 Users: 5 Set LMR
PURG&RNUM - SPORTSM.DEF Purged: 35 Kept: 54 Users: 6 Set LMR
PURG&RNUM - TECHM.DEF Purged: 51 Kept: 53 Users: 6 Set LMR
PURG&RNUM - RBBSM.DEF Purged: 4 Kept: 92 Users: 25 Set LMR
9BA308A0.PKT Tot: 110 Dup: 0 Skip: 0 1:343/300@fidonet 29 QMail 1.0
9BA61FB7.PKT Tot: 87 Dup: 0 Skip: 0 1:343/300@fidonet 29 QMail 1.0
9BA80FE1.PKT Tot: 15 Dup: 0 Skip: 0 1:343/300@fidonet 29 QMail 1.0
9BC7D716.PKT Tot: 7 Dup: 0 Skip: 0 1:343/300@fidonet 29 QMail 1.0
/TOSS/PREP/FIXC/NSTOP/DDA/WDIR/LOCK/DLOG/MUSER:3 MailWaiting
-------------------
AREA Name Domain Recd Dups Kept Sent UMsgs USet SYSOP
---------------------- -------- ----- ----- ----- ----- ----- ----- -----
COMM fidonet 56 0 56 0 0 0 0
CLIPPER fidonet 14 0 14 0 0 0 0
CONSULTING fidonet 4 0 4 0 0 0 0
QUIK_BAS fidonet 19 0 19 0 0 0 0
SCIENCE fidonet 14 0 14 0 0 0 0
SPORTS fidonet 38 0 38 0 0 0 0
TECH fidonet 51 0 51 0 0 0 0
RBBS-PC fidonet 2 0 2 0 0 0 0
NET343 fidonet 2 0 2 0 Fido
NET_DEV fidonet 1 0 1 0 Fido
-------------------------------------------------------------------------
Totals -- Skipped: 1 -- 726 0 726 0 0 0 0
Anal: 1.1 Prep: 1.4 Toss: 2.6 Mwait: 0.6 Tot: 5.7 Toss/Min: 278
MSGTOSS 2.0 provides a list of the purging activity, the *.PKTs processed,
how many messages were in each *.PKT, how many DUPS, how many messages
were skipped due to bad message headers, over sized messages, which mes-
sage bases were expanded, etc. In addition, it provides the command line
switches that were used when executing MSGTOSS. It provides the sysop with
a summary of the mailwaiting status of his system, including himself, and
a summary of how many messages were skipped and the time needed to
complete the major operations of MSGTOSS, including the tossing through-
put.
NOTE: The creation of the MSGTOSS.LOG file is automatic. It is up to you
to delete it at regular intervals. Its location is determined by the
LOGDIR----> parameter.
Page - 25
MSGTOSS Version 2.0
CREATE MISC BAT/CMD/CTL FILES
-----------------------------
MSGTOSS was designed to be extremely flexible, therefore, various system-
related utility batch files can be automatically created. The only message
bases reported are only those which have received new messages. These
BAT/CMD/CTL files are automatically deleted each time MSGTOSS is executed,
therefore the maintenance they call out should be executed immediately af-
ter executing of MSGTOSS. This can be used for a variety of tasks, where
the replacement parameters available are [MSGFILE], [USRFILE], [WELFILE],
and [AREA]. The parameters ONLY apply to RBBS message bases, and not Fido
sub-directories.
Here is a sample of a UTIL(s) commands being used to create automated
batch files for SUBJECT utility:
UTIL1------->SUB.BAT
UTIL1CMD---->SUBJECT I:[MSGFILE] O:[WELFILE] C:[AREA] F:C
Will create a file called SUB.BAT for all those message bases that
actually received messages (RBBS only!). Example:
You receive echomail in the following message bases:
C:\RBBS\RBBSM.DEF, RBBS-PC
C:\RBBS\COMMM.DEF, COMM
C:\RBBS\COOKM.DEF, COOOKING
and you have the above UTIL1 commands, MSGTOSS will create SUB.BAT, that
would look like the following:
SUBJECT I:C:\RBBS\RBBSM.DEF O:C:\RBBS\RBBSW.DEF C:RBBS-PC F:C
SUBJECT I:C:\RBBS\COMMM.DEF O:C:\RBBS\COMMW.DEF C:COMM F:C
SUBJECT I:C:\RBBS\COOKM.DEF O:C:\RBBS\COOKW.DEF C:COOKING F:C
The templates [MSGFILE], [WELFILE] & [AREA] are dynamically replaced, cre-
ating the batch file that can execute SUBJECT.EXE (a very fine utility that
automatically creates welcome files for conferences).
Immediately after the toss SUB.BAT needs to be executed, as the next time
MSGTOSS is executed, it will delete the batch file automatically.
NOTE: MSGTOSS will only replace message bases that contain 'M.DEF'. For
the main RBBS message base 'MESSAGES', a line would NOT be created.
Page - 26
MSGTOSS Version 2.0
SCAN
----
The /SCAN switch is what enables MSGTOSS to send all new messages created
on your system to your host or boss node. The messages can be in the form
of RBBS message bases (M.DEF) or FIDO messages (#.MSG). MSGTOSS can scan
(export) new mail for both formats, either or both simultaneously. In ad-
dition, for hub work, it has the capability to rescan a certain area for a
particular net/node using the /RSCAN switch. It also does a few other use-
ful features.
Related MSGTOSS.BBS keywords: PRIV:x, GATE:x, NODE:x, CDUP:x and NBBS:
Related command line switches (see MSGSWI.DOC for more info)
/SCAN /RBBS /FIDO /LOCK /FIX /FIXC, /DDA (basic)
/RSCAN: /HWM /CFG: /BBS /WDIR /AREAF: /AREA: (advanced)
PRIVATE MESSAGES
----------------
Configured by the MSGTOSS.BBS keyword PRIV:x, you can tell MSGTOSS what to
do in the event of finding a private message while scanning. Here are the
basic rules:
If COMMENT will not be exported (ever)
If PRIVATE and TO:SYSOP will not be exported
If PRIVATE and TO:USER and PRIV:1 then export (priv set)
If PRIVATE and TO:USER and PRIV:0 then DON'T export
The term USER means an active user in the U.DEF for the specified M.DEF.
If the message is an authorized private message, MSGTOSS will set the pri-
vate bit for the message. For more information, see PRIV:x in MSGBBS.DOC.
SCANNING PHILOSOPHY
-------------------
Feeding NODES is a function of /FEED, and is --> NOT <-- done from RBBS
message bases. Basically this means that the exporting of mail via the
/SCAN is ONLY intended for "locally" entered mail, and also for re-scanning
to a net/nodes when needed. Reasons (also see EXCEPTION):
MSGTOSS does NOT follow the same rule like RBBSMAIL where it builds a new
message bases to insert the SEEN-BY and PATH lines. The SEEN-BYs and PATHs
are exported, but the message base does NOT physically change. Any exist-
ing SEEN-BYs and PATHS in RBBS message bases are simply ignored, and
MSGTOSS will export a short SEEN-BY and PATH that only contains your system
and the nodes it feeds.
The requirement to re-build a message base while scanning is not desirable,
(sorry RBBSMAIL) as this prevents the ability to SCAN while users are on
-line. The MSGTOSS method allows absolutely safe scanning of mail continu-
ously, even if 20 nodes are active.
Page - 27
MSGTOSS Version 2.0
This makes it practical to always use the FMAS:1 bbs keyword, because in
theory your downstream nodes have ALREADY feed via the /TOSS/FEED. Clear?
EXCEPTION: If you are re-scanning from a FIDO area (#.MSG), MSGTOSS will
correctly maintain the SEEN-BY: and PATH: lines. The reason is
that MSGTOSS tosses SEEN-BY and PATH lines to a FIDO area, but
not (usually) to an RBBS message base.
MIRROR SCANNING
---------------
MSGTOSS 2.0+ provides a notable feature called "mirror-scanning", where if
you have a double-tossed area (RBBS + FIDO, for one area), then if a user
entered a message in the RBBS conference, when exported, will also create a
"carbon copy", complete with Origin: line, in the Fido-Style directory as
well. The same applies to when a user (or yourself) enters a message in a
Fido-Style conference, when exported, will create a carbon copy in the RBBS
message base.
There are four phases to a scan operation:
1 Initialization
2 Scan RBBS message bases
3 Scan FIDO message areas
4 Creates Log File
INITIALIZATION
--------------
During initialization, MSGTOSS will read your MSGTOSS.BBS to see who your
host, points, and feeds are. It will also check the nodelist to see if it
is current. If your nodelist is not current it will give you a warning
and continue processing. If you specified the /LOCK command it will enable
the appropriate file locking method in accordance with the LOCKTYPE---->
parameter prior to scanning.
NOTE: The whole /SCAN operation can be executed safely even though us-
ers are on-line, as MSGTOSS will use full multi-tasking/network
record locking protocols (using /LOCK, as defined by LOCKTYPE--
--->) during a /SCAN, allowing fully safe scanning.
NOTE: MSGTOSS expects all of your RBBS message bases and fido directories
to properly exist prior to scanning. You should have run /TEST be-
fore this to make sure you are properly setup, as /TEST will also
check for these directory conflicts. It will also tell you if you
are missing a message or user base.
If the bbs keyword CDUP:1 (check for duplicates) is active, MSGTOSS will
load all of its keys into memory. MSGTOSS will store all of the MSGID CRC
codes into the MSGTOSS.EID file after it exports a message. During a /TOSS
operation, if the same message shows up (maybe caused by an improper host
link), it will be ignored. For more information, see CDUP:x in the
MSGBBS.DOC file.
NOTE: To obtain the fastest scanning/tossing throughput, avoid using CDUP:1
(use CDUP:0) unless you have a real problem with duplicates.
Page - 28
MSGTOSS Version 2.0
SCAN RBBS MESSAGE BASES
-----------------------
To initiate the scanning of RBBS message bases, you need to specify /RBBS
on the /SCAN command line. MSGTOSS will first attempt to read the High Wa-
ter Mark (HWM) in each of the RBBS message bases. For RBBS message bases,
this is located in position 121-122 of the checkpoint record. The HWM is
stored as the RECORD number of the HWM message. If the HWM is valid (i.e.
the record number is a true header), MSGTOSS will ignore all previous mes-
sages prior to this record. See /HWM & /SCAN (in MSGSWI.DOC) for more in-
formation.
NOTE: During a MSGTOSS purge operation (/SIZE or /PREP), MSGTOSS will reas-
sign the HWM to its new value automatically.
WARNING: If you decide to use another purging utility (CONFIG, MU-PURGE,
HUH, etc.), then the HWM located at position 121-122 will become
screwed up! For the most part, MSGTOSS will figure out that the
HWM is not proper, and start scanning from the first message. Us-
ing another purging utility will cause the MSGTOSS /SCAN operation
to be slower.
NOTE: The /HWM switch provides a means of forcing MSGTOSS to ignore the
HWM, and start scanning from the first message. If you have used an-
other purging utility, or you are not sure if a message was exported,
try using the /HWM switch.
While scanning an RBBS message base, MSGTOSS will look at the second digit
of the TIME field (position 64 of the message header) for the presence of a
':' (colon), and if present, will export the message. After exportation,
MSGTOSS will change this colon to a '.' (period) to 'MARK' it as being
scanned.
NOTE: This is the same scheme that RBBSMAIL uses to mark messages as
scanned.
When MSGTOSS has finished exporting an M.DEF message, it will append a
'<XMT>' to the bottom of the message, allowing users or the sysop know that
the message has been exported. During a MSGTOSS purge operation (/PREP or
/SIZE), MSGTOSS will replace these <XMT> lines with the defined origin line
(can be configured via ORGN: keyword(s)). The reason for this odd method
is to allow full scanning features while users are on-line.
NOTE: MSGTOSS will NOT fragment the RBBS message bases during a /SCAN oper-
ation (or /TOSS for that matter!).
MSGTOSS will open *.OUT files to their respective net/nodes, as defined by
the net/node listing for each area in the MSGTOSS.BBS file. During the scan
session, these *.OUT packet(s) are generated on the fly and closed at the
end of the scan process.
NOTE: MSGTOSS uses the *.OUT format, which is a standard format used for
many Fidonet compatible systems. These *.OUT files are normally
packed by a program called Ommm (1.5+ recommended) and some other
packers. If you are running a file-attach mailer (Frontdoor,
Page - 29
MSGTOSS Version 2.0
DBridge, etc.) you will need a special packer that will convert these
*.OUT files to support their file-attach method. MAKEARC is a recom-
mended packer for these types of systems.
During its search of the RBBS messages bases it will give you a display on
the screen of what it is doing and what it found in each message base.
This is a typical display for a few RBBS message bases.
Scanning Message Bases
Msg New Num Num Msgs Total
Area Name Domain MsgBase Num Msgs Priv Nodes Sent Sent
--------------------- -------- ------- ----- ----- ----- ----- ----- -----
MAC fidonet MAC 339 6 0 4 6 24
APPLE fidonet APPLES 529 1 0 1 1 1
ASKACOP2 fidonet POLICE 334 0 0 0 0 0
AMIGA_PROG fidonet AMIGAPR 45 0 0 0 0 0
Because there are 4 nodes that get files from the MAC area the total mes-
sage sent out was 24 (4 * 6). Most people will just be sending messages
to one place and then the second line would be much more common. The 'Num
Priv' column indicates the number of private messages exported.
SCAN FIDO MESSAGE AREAS
-----------------------
To initiate the scanning of FIDO message areas (#.MSG), you need to specify
/FIDO on the /SCAN command line. It will use the MSGTOSS.BBS to find the
path to these messages, use its high water mark (1.MSG) and SEEN-BY lines
to determine which net/nodes the message needs to be sent to. When ex-
porting a FIDO message (#.MSG), MSGTOSS will set the 'sent' bit, preventing
re-exportation. The On screen display will look like this.
Scanning Message Bases
Msg New Num Num Msgs Total
Area Name Domain MsgBase Num Msgs Priv Nodes Sent Sent
--------------------- -------- ------- ----- ----- ----- ----- ----- -----
NET935 rbbsnet *.MSG 55 2 0 4 4 16
RBBS_MSGTOSS rbbsnet *.MSG 101 1 0 1 1 1
RBBS-ADA rbbsnet *.MSG 98 5 0 2 5 10
After going thorough all the areas it will then close the *.out files and
display the time it took to do the scan and provide listing of the ad-
dressees the packets are going to and how many messages were sent to each
address. Here an example:
Scanning took 17.4 seconds.
Sent 40 message(s) to 1:271/270@fidonet
Sent 2 message(s) to 1:271/260@fidonet
Sent 10 message(s) to 1:271/280@fidonet
You now have the *.OUT file(s) in your OUTBOUND-----> directory(s) for the
domain that it was created for. These *.OUT files will still need to be
packed by the appropriate packer (Ommm for Binkley systems, MAKEARC for
file-attach systems). Also see OUTBOUND----> in MSGCFG.DOC for more
Page - 30
MSGTOSS Version 2.0
information on this.
RE-SCANNING TO NET/NODES
------------------------
If you are a hub, you can have MSGTOSS re-scan messages to new net/nodes.
For more information, see /RSCAN:xxx,xxx,xxx in MSGSWI.DOC. Also throughly
understand the MSGTOSS scanning methodology as discussed in this section.
CREATE LOG FILE
---------------
MSGTOSS after the completed scan will copy the exact display you saw on
the screen to the MSGTOSS.LOG file. If the file doesn't exist it will cre-
ate it. So you can delete it any time you want, But not during processing
please.
Page - 31
MSGTOSS Version 2.0
DOMAIN & ZONE AWARENESS
-----------------------
Alot of mail processors CLAIM to be ZONE and/or DOMAIN aware. What
does that mean? The authors of MSGTOSS really mean business when we
claim MSGTOSS is domain/zone aware, more than any other known mail
tosser, and by all means any other RBBS-PC mail processor.
DOMAINS & ZONES - DEFINED
-------------------------
A domain is defined to mean any combination of ZONES/NETS & NODES
within a particular boundary. For instance, Fidonet, Rbbs-Net, Sig-
Net, Alternet, Eggnet, etc.. are each a unique domain.
Per definition, each domain may have combinations of zones, nets and
nodes which may overlap between other domains. For instance:
1:343/300.0@fidonet
2:343/300.0@fidonet
1:343/300.0@Sig-net
1:343/300.0@Zak-net
All are perfectly fine, although the same net & node are the same, the
zone/domain is different, and they each have unique identifiers.
THE BASIC PROBLEM
-----------------
Mosts mail processors are not that smart, and only provide the NET and
NODE of the PKT. Some mail processors provide the ZONE of the packet.
Generally, if identical mail processors pass mail back and forth,
and they both support zones then a great deal of accuracy can
achieved as far as zone-awareness is concerned. If a message is ad-
dressed to 1:343/36@fidonet, and I am that address, no problem.
However if mail is being routed THROUGH you, and was packed by a zo-
ne-dumb packer, even the so-called zone-aware mail processors would
have no idea what zone it is, and will probably toss the message into
the default zone directory.
MSGTOSS has totally eliminated the basic problem and positively
identifies the domain & zone, even though the sender was using a
zone-dumb processor. MSGTOSS accomplishes this via its own proprietary
nodelist which is updated/created along with the weekly nodelist pro-
cessing (this is explained further in the document). Along with some
clever programming and logical guessing, MSGTOSS will be able to fig-
ure out the correct origination & destination domain/zone/net & node
of the PKT, and even provides an assessment as to the reliability
of the domain/zone identification procedure.
This is further processed by tossing the message into a separate
NETMAIL directory for each unique DOMAIN. For instance, if you be-
long to both Fidonet and Rbbs-Net, you could have two separate
directories, one for each domain. For instance:
C:\NMAIL\RBBSNET\
C:\NMAIL\FIDONET\
Page - 32
MSGTOSS Version 2.0
This is configurable via the ZONETYPE----> parameter. For all netmail,
you can configure the following:
ZONETYPE 1 - Singled directory for all netmail from ALL domains & zones
ZONETYPE 2 - Mult directories for each unique domain (as above)
ZONETYPE 3 - Mult directories for each unique zone within each domain
During system setup or debugging (/TEST switch), MSGTOSS will complain
loudly if it finds inconsistencies between ZONETYPE and directory
structure.
For echomail, you define what domain a particular echomail conference
belongs to. The zone is not important, as most conferences are
shared via multiple zones per domain. For instance, the Fidonet RBBS-
PC echo is echoed throughout Fidonet (a domain) and not just one
zone. On the other hand, Rbbs-Net also has an RBBS-PC echo, which is
gate routed to them. Any other mailprocessor would get confused, but
MSGTOSS is able to keep the two conferences (Fidonet & Rbbs-Net) to-
tally separate, even though they have the same name! This is
accomplished by the destination address of the PKT. For instance,
suppose you received two echoes by the same name, but a different do-
main: Your addresses where:
1:343/36.0@fidonet
8:918/10.0@rbbs-net
Each having a totally separate conference area called 'RBBS-PC'
If a host sends echomail to 8:918/10, then RBBS-PC messages will
be tossed into the totally separate RBBS-PC conference/directory
as defined for domain rbbs-net, and leave the defined fidonet con-
ference alone. No other mail processor in the world provides this
amount of domain/zone separation capability.
Page - 33
MSGTOSS Version 2.0
NETWORK/MULTI-TASKING SUPPORT
-----------------------------
When using the /LOCK command line switch, MSGTOSS will use RBBS NETBIOS,
DESQVIEW, PC-NET or 10-NET conventions in accordance with the LOCKTYPE--->
parameter. This is used during tossing, scanning, purging, renumbering, &
sizing message bases. Because purging can sometimes take long periods of
time (especially if executing in a slow background DESQVIEW window),
MSGTOSS supports two special CFG parameters, LOCKWAIT---> and LOCKTIME---
>. Both of these CFG parameters affect purging/tossing/resizing opera-
tions. MSGTOSS will lock and un-lock the message base using the proper
RBBS conventions whenever necessary, but due to MSGTOSS's speed these pa-
rameters were required to slow it down in a controlled manner.
If LOCKWAIT---> is a value greater then 0, whenever MSGTOSS releases a
message base it will WAIT xx seconds prior to continuing. The XX can be
as small as ".01" so extremely small amounts of delay are possible. The
idea behind the wait is to allow other nodes a chance to lock the message
base (while another user is entering a message) and MSGTOSS is forced to
wait until the other node is finished.
If LOCKTIME---> is a value grater than 0, then whenever MSGTOSS locks a
message bases LONGER than XX seconds (5 seconds recommended) it will stop
what its doing (purging/tossing/resizing), reset the message base check-
point records, wait for LOCKWAIT---> seconds, then continue what it was
doing. This allows other nodes a chance to break in while MSGTOSS is doing
a long purge or other operation.
MSGTOSS will (during /TOSS & /SCAN) flash "status" lights in the lower
right-hand corner of the screen indicating if a message/user base is
locked.
EFFECTS OF PURGING WHILE USERS ARE ON-LINE
------------------------------------------
It should be noted that no ill effects have been noticed during exten-
sive beta testing as to the effects of purging messages while users
are on-line, however, some anomalies exist that are noteworthy.
If a user is active in a conference while MSGTOSS is busy purging
messages, the user may become confused as to why messages suddenly
disappear. This is normal, as when the user joined the conference, all
of the locations of the message headers were written into memory by
RBBS-PC, and RBBS-PC doesn't expect these locations to change. This
doesn't seem to hurt the message base.
When MSGTOSS finally gets around to actually tossing messages, then
messages will suddenly re-appear, most likely garbled, as mentioned
earlier, RBBS-PC expects the headers to be where they were when the
user first joined the conference. The usual response of the user is
to:
1) Panic (what did I do!)
2) Hang-up and call again
3) Re-join the main message base and enter a COMMENT to the
Page - 34
MSGTOSS Version 2.0
Sysop stating that something is wrong.
NOTE: If you find this intolerable, you can elect to simply use the
/PREX (pre-expand) switch and the user will never be affected by
this. However, remember that pre-expanding the message will re-
quire it to be chopped down "SOONER than LATER" (quote from
George Bush prior to attacking IRAQ) via the MSGTOSS /SIZE
switch.
However, an astute user can simply enter the '[P]ersonal Mail' func-
tion to re-load all of the message header keys and all will return to
normal (assuming MSGTOSS is done).
If a user was busy entering a message base during this time peri-
od, he/she shouldn't be affected while MSGTOSS was in the back-
ground. RBBS-PC will first obtain updated checkpoint information
from the message base prior to writing the message information, and
MSGTOSS is constantly updating this record during its purging process.
MSGTOSS never expects another process to be purging message bases at
the same time it is! What this equates to is attempting to run TWO
(or more) MSGTOSS processes at the same time is asking for corrupt
message bases! However, if you must do this (reasons unknown to my-
self) you can avoid problems by having each MSGTOSS process use a
different MSGTOSS.BBS file, to make sure they don't collide by purg-
ing the same message base. Theoretically, TWO (or more) MSGTOSS pro-
cesses can exist during TOSSING, but purging is where problems may
arise.
For the most part, most users will be unaffected by MSGTOSS purging
in the background, other than the speed of the system will show it.
NOTE: As of this writing, a rather irritating bug exists in RBBS-PC, where
if a NEWUSER is logging on, RBBS-PC will lock the USER base until the
user has succesfully (totally finished) logs on. This equates to
MSGTOSS waiting (flashing user base flag) until the NEWUSER is fin-
ished answering all of the questionnaires, etc. This is the only
known cause of MSGTOSS seeming to apparantly LOCK-UP (with locking
status lights). If you notice this, its RBBS, not MSGTOSS.
MSGTOSS AS A USER
-----------------
While MSGTOSS is busy in the background, you can have it constantly update
one of the RBBS-PC node-records of the main message base via the /MUSER:x
command line switch, where x is the node number MSGTOSS will permanently
occupy. A user entering [W]ho else is on can see something similar:
Node 1 Online at 9600 BAUD: SYSOP KENT ,WA
Node 2 Online at 2400 BAUD: JOHN HENDRICKS SEATTLE,WA
Node 3 Online at 9600 BAUD: MsgToss 2.0-Mail System PURGING MSG BASES
For more information, see MSGSWI.DOC on this.
Page - 35
MSGTOSS Version 2.0
INSTALLATION
------------
MSGTOSS is a very extensive program and covers every aspect required for a
ECHOMAIL tosser and scanner. If this is your first time trying to use
MSGTOSS, I advise you use all the default examples listed. If you have a
problem, use the reference manuals to fine tune that area. This section
will try to lead you through the installation process Step by Step.
MSGTOSS probably should be in a directory all by itself. This will help
you understand what files are for it and what it does. You will need to
find a drive that has enough room which is about 600K for a small system
and up to about 1.5 meg for systems that have around 120 echomail areas.
The MSGTOSS.LOG will increase in size during each action taken. Another
variable is the MSGTOSS.EID table. It's size is controlled by the
MSGTOSS.CFG file. Other than these concerns nothing should matter where you
put it. The echomail packets that you get can go anywhere, as long as you
inform MSGTOSS where they are (via FILES-------> parameter(s). We will be
using C:\MSGTOSS as the drive for the setup.
There are 11 steps to installing MSGTOSS:
1) Create MSGTOSS directory
2) Copy files to MSGTOSS directory
3) Print & read documentation
4) Modify sample MSGTOSS.CFG
5) Modify sample MSGTOSS.BBS
6) Modify default MSGTOSS.BBS Keywords
7) Create MSGTOSS.NOD using MSGNLST.EXE
8) Test system setup
9) Mail tossing test
10) Mail scanning test
11) Batch file modification.
CREATE MSGTOSS DIRECTORY
------------------------
Although having its own directory is optional, it may simplify things to
begin with. Personally, I placed it in the same directory where the mailer
is, like C:\BT\ or C:\FD, or whatever. Or maybe C:\MSGTOSS
COPY FILES TO MSGTOSS DIRECTORY
-------------------------------
Copy all the files from the registered disk into your directory or all the
files from the shareware disk and un-compress them into your selected di-
rectory.
The following files are required to run MSGTOSS.
MSGTOSS.COM (program: Spawns MSGTOSS1.OVR)
MSGTOSS1.OVR (program: Main MSGTOSS overlay file)
Page - 36
MSGTOSS Version 2.0
MSGNLST.EXE (program: Nodelist compiler, creates MSGTOSS.NOD)
MSGHELP.EXE (program: DOS-help for setting up MSGTOSS)
MSGEID.EXE (program: EID database maintenance utility)
MSGTOSS.BBS * (modify ... to suit your message bases)
MSGTOSS.CFG * (modify ... to suit your system configuration)
MSGTOSS.CMD * (modify ... MSGTOSS metacommands - advanced)
MSGTOSS.PCD (contains product codes for all known mailers)
MSGTOSS.EID (created by MSGTOSS - EID database for dup checking)
MSGTOSS.NOD (created by MSGNLST from raw nodelist(s))
MSGTOSS.DOC \ (this file)
MSGCFG.DOC \
MSGBBS.DOC > Printing (and reading) these are mandatory!
MSGSWI.DOC /
MSGIDX.DOC / (Integrated INDEX)
After you set up Msgtoss it will create a few others that are necessary to
run itself.
PRINT DOCUMENTATION
-------------------
Print out all of the documentation for MSGTOSS, especially the MSGCFG.DOC,
MSGSWI.DOC, and MSGBBS.DOC, as you will be referring to them alot during
setup.
READ DOCUMENTATION
------------------
Yes there is alot of documentation associated with MSGTOSS. Make addition-
al copies for your livingroom, bathroom, bedroom, and work areas (just kid-
ding). You really need to grasp the total picture of how it all fits to-
gether, and the only way to do this is to read it. MSGTOSS is really not
one of those programs you can just un-arch, find the BAT or EXE files, and
just enter it at the command line. You can, however, just enter:
MSGTOSS <rtn>
And a summary of the command line switches will appear. You will appreci-
ate it later when you try to figure out what command line switches to use.
For now, just know that MSGTOSS <rtn> will provide some assistance at a
later time, AFTER YOU READ THE DOCS!
Quite possibly every question you have is probably answered in the documen-
tation. Remember... RTFM (read the *uckin manual).
Also, don't overlook the MSGIDX.DOC integrated INDEX. Should point you to
all references for a given major subject. Use it to get the most out of
the documents.
Page - 37
MSGTOSS Version 2.0
MODIFY SAMPLE MSGTOSS.CFG
-------------------------
Since you took heart to the last paragraph, you shouldn't have any problems
what-so-ever modifying your MSGTOSS.CFG file properly. Most of the parame-
ters are already set up for you... Here are the critical ones you MUST mod-
ify (and understand) before continuing:
CRITICAL MSGTOSS.CFG PARAMETERS
-------------------------------
Address related parameters
--------------------------
DOMAIN------>fidonet.org 1 C:\MAIL\nodelist
NODE-------->1:343/36.0@fidonet
POINTNET---->30174 (only if you support points)
REMAP------->1 Rich Englich (only if you support points)
NOTE: The NODE--------> parameter(s) are extremely critical, as it is
tied to the MSGTOSS.BBS keyword 'NODE:x'. You MUST thoroughly
understand how these are linked. Read MSGCFG.DOC and MSGBBS.DOC
for more information.
NOTE: The DOMAIN------> parameter(s) point to where all of your Saint
Louis Format nodelist(s) are. These are used by MSGNLST.EXE to
create MSGTOSS's proprietary nodelist called MSGTOSS.NOD.
NOTE: The POINTNET----> and REMAP-------> parmameters can be blank if
you don't support points.
Mail and File Forwarding authorizations
---------------------------------------
MAILFROM---->1:343/* 8:918/*
MAILTO------>1:343/* 8:918/*
FILEFROM---->
FILETO------>1:343/* 8:918/*
NOTE: Only used for mail/file routing. If you are not a hub, set all
of these to simply "" (blank), meaning no routing. If you do
route, thoroughly understand how you can shoot yourself in your
pocketbook by incorrectly setting these <grin>.
Sysop key names
---------------
SYSALIAS---->SUPER TOSSER
SYSNAME----->!MIKE ZAKHAROFF
SYSNAME----->=SYSOP
NOTE: The FIRST sequential SYSNAME-----> must be your FULL public
name, preceded by an "!" (as above). This is the name MSGTOSS
will place in outgoing messages from the SYSOP.
Miscellaneous directories
-------------------------
Page - 38
MSGTOSS Version 2.0
FILES------->C:\MAIL\FILES\
OUTBOUND---->C:\OUTBOUND\
WORKDIR----->L:\
Two important RBBS message bases
--------------------------------
MESSAGES---->C:\RBBS\MESSAGES
BLANKMSG---->C:\RBBS\BLANKM.DEF
NOTE: If you are running MSGTOSS on a non-RBBS system (you are only
supporting #.MSG messages), then you MUST set both of these to
"" (blank). An entry here tells MSGTOSS that you are running a
full-blown RBBS system.
Multi-tasking/network support
-----------------------------
LOCKTYPE---->NETBIOS
RBBS purging related parameters
-------------------------------
YEAR-------->1992
Duplicate checking related stuff
--------------------------------
MAXAREAS---->100
DUPSIZE----->500
NOTE: The above critical parameters are in the same order as the sample
MSGTOSS.CFG. You should attempt to understand all of the other pa-
rameters (besides the above) too, as you will want to become familiar
with them at a later date.
IF YOU ARE NOT RUNNING RBBS-PC
------------------------------
If you wish to use MSGTOSS for just its #.MSG support, and don't need or
care to use its exclusive RBBS-PC functions, set the following MSGTOSS.CFG
parameters to blank:
MESSAGES----->
BLANKMSG----->
This will tell MSGTOSS that you are strictly running a #.MSG system (like
Qmail, Confmail, etc.). Don't try using /LOCK.
Page - 39
MSGTOSS Version 2.0
MODIFY SAMPLE MSGTOSS.BBS
-------------------------
Assuming you have read the MSGBBS.DOC file with great interest, you are now
ready to modify the sample MSGTOSS.BBS file to suit your system. You will
need to refer to MSGBBS.DOC constantly during modification, especially when
configuring the BBS keywords.
If you have no idea what an MSGTOSS.BBS "keyword" is, you should STOP here,
READ the MSGBBS.DOC, and continue on.
Here are some high-level basics, not intended to replace the reference man-
ual. MSGBBS.DOC is a pretty good reference, and should answer any ques-
tions you have. You MUST understand its concept, as its more complicated
than a regular AREAS.BBS file. We will start with the RBBS message bases
first.
If you are already running RBBSMAIL, CONFMAIL, or QMAIL, simply copy your
existing AREAS.BBS file as MSGTOSS.BBS, and make the necessary changes.
For an RBBS message-base:
C:\RBBS\rbbsm.def RBBS-PC 1:271/245 271/270 271 8:935/1 90:83/0
^ ^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^
| | | |
Path to messagebase | | |
| | |
AREA:TAG_NAME | |
| |
Who you Receive it from |
|
Who YOU send it to, but
only if you are a HUB!
Examples:
C:\RBBS\lchatm.def LCHATTER 271/245 271/250 271/300 6666/10
C:\RBBS\lovem.def LOVELINE 271/245
A FIDO-style area (#.MSG):
C:\MAIL\LCHATTER\ LCHATTER 271/245 271/250 271/300 6666/10
C:\MAIL\LOVELINE\ LOVELINE 271/245
Notice that the only difference between these two is that the first entry
is a true sub-directory, ending with a trailing backslash.
Modify MSGTOSS.BBS for all areas you support on your system.
MSGTOSS has hard-coded AREAS with special names, these are:
NETMAIL - Where non-echomail (Netmail) is tossed
UNKNOWN - Where unidentified echomail is tossed
ROUTETHRU - Where Netmail (not addressed to your AKAs) are tossed
Page - 40
MSGTOSS Version 2.0
MSGCAPTURE - Where "captured" echomail is tossed
NOTE: For all of the above special hard-coded areas, separate directo-
ries must be defined for each unique Domain/Zone, as indicated by
your ZONETYPE----> entry in your MSGTOSS.CFG. Refer to
MSGCFG.REF for detailed information.
NOTE: The AREAs NETMAIL and UNKNOWN are required for all MSGTOSS
installations, where ROUTETHRU and MSGCAPTURE are optional.
See MSGBBS.DOC for additional information on these special areas.
As detailed in MSGBBS.DOC, it is recommended that NETMAIL be a "double-
tossed area" where you have both FIDO area (#.MSG) and an RBBS message base
(M.DEF). Here is an example:
C:\RBBS\MAINM.DEF NETMAIL (no net/nodes listed!)
C:\MAIL\NETMAIL.001 NETMAIL (no net/nodes listed!)
The area UNKNOWN should be a FIDO area, as follows:
C:\MAIL\UNKNOWN.001 UNKNOWN (no net/nodes listed!)
NOTE: All areas except NETMAIL, UNKNOWN, ROUTETHRU & MSGCAPTURE should have
at least one address present.
MODIFY DEFAULT MSGTOSS.BBS KEYWORDS
-----------------------------------
You must understand the concept of "keywords". Read MSGBBS.DOC if you are
still confused as to what they are. Setting them incorrect will thoroughly
screw things up!
The following are the critical MSGTOSS.BBS keywords. All other keywords
can be left as-is for now, until you better understand them.
NODE:xxxx RECS:xxxx, ESEC:xxxx, GATE:xxxx, FMAS:x, SECL:x, USRH:x
NODE: Tied to the MSGTOSS.CFG file. NODE:1 would be the first NODE
address in your MSGTOSS.CFG file. NODE:2 means second, etc.
NOTE: The keyword is extremely critical if you belong to multi-
ple zones/domains (Fidonet & Rbbs-Net), as it is linked
to MSGTOSS.CFG NODE--------> entries. Changing one
(without changing the other) will probably screw things
up.
RECS: The number of records your message-base is using. It is listed
in CONFIG Parameter # 165. This one can be different for each
message area. If so you will need the size difference above
each message area.
NOTE: This is probably the most important keyword. Setting
these wrong may chop your message bases in size.
Thoroughly read MSGBBS.DOC on this keyword for sure.
Page - 41
MSGTOSS Version 2.0
NOTE: When executing the /TEST function, MSGTOSS will report to
you (bright white/red) whether you have any RECS:xxx set
improperly.
ESEC: The security the messages are set to. This is configurable for
each area. If you have an Adult area that needs higher security
levels for the messages put a -ESEC:20 in above the message-
base line. BUT! Remember to set it back down to the lower lev-
el, or else all following areas will have the same higher lev-
el.
GATE: Use GATE:2 (always!)
FMAS: Use FMAS:1 (unless you thoroughly understand it)
SECL: Use SECL:1 (unless you thoroughly understand it)
USRH: Use USRH:1 (U.DEFs with few (less than 100) users, else 0)
NOTE: Additional information on the above keywords exist in MSGBBS.DOC, and
should be read (and understood) prior to configuring.
Again.... You MUST read the purpose and function of all keywords so you
can get the most out of their capabilities. Using the combination of the
sample MSGTOSS.BBS file, MSGBBS.DOC, and common sense, you will figure it
out. Patience!
Page - 42
MSGTOSS Version 2.0
CREATE MSGTOSS.NOD USING MSGNLST.EXE
------------------------------------
MSGTOSS creates its own special nodelist called MSGTOSS.NOD. It will
build this table using the nodelists you specify in your MSGTOSS.CFG file
after the DOMAIN------>. It will then look at each listing and display
information while it is executing. If there is a problem it will tell you
at the end.
Example: DOMAIN------>fidonet.org 1 C:\MAIL\NODELIST\nodelist
DOMAIN------>rbbs-net.org 8 C:\MAIL\NODELIST\rbbslist
The above point to two sets of nodelists. MSGNLST will only use the node-
lists that have the greatest extentions. So if you have two nodelists (af-
ter parsing) as follows:
RBBSLIST.007, RBBSLIST.014
MSGNLST will choose the 014 nodelist, and ignore the 007 (older) version.
Thoroughly read (and understand) MSGCFG.DOC section on DOMAIN------> and
MSGSWI.DOC on /NLST before continuing on. Understand that compiling the
MSGTOSS nodelist (MSGTOSS.NOD) should be done as part of your weekly nodel-
ist processing (nodediffs, etc.). Somewhere in your batch file you need to
change drive/directory back to where MSGTOSS.CFG is, execute MSGNLST.EXE,
and then continue.
This is the common output (of MSGNLST.EXE) at the beginning. The non-uni-
que net/nodes are normal operation. You will see hundreds of them.
-------------------------------------------------------------------------
MsgNlst version 2.0+ -- Copyright 1992 Mike Zakharoff, Warren Muldrow
Enough memory is available for a maximum of 35606 nodes.
Processing domain: fidonet Node list: C:\MAIL\NODELIST\nodelist.354
Non-unique net/node: 1:201/0@fidonet 2:201/0@fidonet
Non-unique net/node: 1:203/0@fidonet 2:203/0@fidonet
Non-unique net/node: 1:203/101@fidonet 2:203/101@fidonet
-------------------------------------------------------------------------
MSGTOSS.NOD is created by running either:
MSGTOSS /NLST <rtn> -- or --
MSGNLST <rtn>
It will then look for the DOMAIN and files that you have listed in your
MSGTOSS.CFG file. If it is all correct it will return you to the DOS
prompt with no errors. It does display alot of NON-UNIQUE Node numbers,
that is perfectly normal. It uses these to build itself an internal table.
If you have errors it will probably be in your MSGTOSS.CFG. Most errors
are because it couldn't find the nodelist files. This is corrected by
changing the DOMAIN path and filename to the correct one.
Page - 43
MSGTOSS Version 2.0
TEST SYSTEM SETUP
-----------------
MSGTOSS has a built in test switch that allows you to test your setup. It
will show you any problems that you have or any setup parameters that
might have been messed up. It will test your files that can be open and
all message-bases and give you a summary of all RBBS message bases. If you
are getting weird data out of a message base, you should run FIXMSG.EXE on
the message base. If it still does not fix it, delete the message base
and create a new one.
NOTE: See MSGSWI.DOC for more information on /TEST.
ENTER the command:
MSGTOSS /TEST
What you should see....
-------------------------------------------------------
/TEST
Initializing - MSGTOSS.CFG
Initializing - No File Locking Active
Initializing - MSGTOSS.BBS oooooooooooooooooooooooooooo
-------------------------------------------------------
If you have a problem in this area it probably be with your MSGTOSS.CFG or
you MSGTOSS.BBS files. The errors messages should be good enough for you
to understand the problem. If not ... yes ... read some more docs!
The next set of display items is be these.
-------------------------------------------------------
Unique NET/NODE Index: 1 - 1:271/270@fidonet
Unique NET/NODE Index: 2 - 1:271/271@fidonet
.....
Unique NET/NODE Index: 37 - 65:511/1@ournet
Unique NET/NODE Index: 38 - 65:511/236@ournet
Unique Nodes Detected - 38 Minimum FILES=XX is 49
Max nodes for single area is 22
Default Origin line:
* Origin: Virginia Data Exchange (804)877-3539 -2-Lines- FREE(Address)
Press any key for file handle test
--------------------------------------------------------
MSGTOSS is looking at your nodes and feeds to see if everything is correct.
You need to look at each UNIQUE NET/NODE and make sure this are valid areas
that you have or you send mail to. If there is something wrong with these
address, then you probably have something wrong in your MSGTOSS.BBS file.
If so, go back and redo steps 3, 4, 5 and 6.
This step also gives you an IMPORTANT piece of information. It tells you
how many more FILES are going to be needed for your MSGTOSS operation.
Above it says Minimum FILES=XX is 49. What this means is to run MSGTOSS on
a non multitasking system that is the most files that will be opened at
Page - 44
MSGTOSS Version 2.0
once. But if you run other windows you will need to increase your CON-
FIG.SYS by this number.
THE NEXT SCREEN will be the file handling test.
---------------------------------------------------------
Opening test file 1
...
Opening test file 42
Opening test file 43
Opening test file 44
Any key for DUPFILE test
May create MSGTOSS.EID during this phase (if CDUP:1 was found)
.....
Any key to for statistics
----------------------------------------------------------
This is another potential area for errors. MSGTOSS is making sure it can
open all the files it needs for maximum operation. If you multi-task, you
will probably need additional file handles, over and above to recommended
values shown. All you need to do is increase the size of your CONFIG.SYS.
THE NEXT SCREEN. MSGTOSS will give you statistics on each RBBS messagebase.
----------------------------------------------------------
Name Usr N Lvl Recs Used Free Full Msgs Msg Msg Size Cap Msg Msg
------- --- -- --- ---- ----- ---- ---- ---- ---- ---- ---- ---- ---- -----
IBM 486 4 0 2505 1563 942 62 500 1003 472 3.3 757 1003 10-09
MAC 66 4 0 1024 691 333 67 204 404 119 5.8 176 404 11-16
APPLES 13 4 0 2464 2178 286 88 492 259 259 8.4 293 259 12-09
AMIGAEC 16 4 0 6352 4329 2023 68 999 445 445 9.7 653 445 12-11
AMIGAME 12 4 0 1392 946 446 68 278 220 220 4.3 324 220 12-23
ATARI-8 4 4 0 992 670 322 68 198 521 90 7.4 133 521 12-16
... etc.
---------------------------------------------------------------------------
Tot:There are 14106 messages in 73 areas averaging 5.7 records per message.
The 14.4 Mb allocated should hold 20474 total messages.
There are 37203 unused records out of 118167 allocated.
----------------------------------------------------------
This screen is very useful in determining what the status is on all your
RBBS messagebases. If you get weird numbers like -.9854 or any negative or
fractions. You probably have a corrupted message base. It might still work,
but the header information is bad. Try using FIXMSG.EXE on those messages
to fix them. If that doesn't work delete them and rebuild them.
During the /TEST display, MSGTOSS will pause every 23 lines allowing you to
view the message bases. In addition, if any of your MSGTOSS.BBS REC:xxx
keywords don't match the actual size of the message bases, MSGTOSS will re-
port to you (white on red) the fact that this error exists. The messages
is placed in the right-hand corner of the status line. The error would
look similar to this:
APPLES 13 4 0 2464 2178 286 88 492 259 259 8.4 293 RECS:500
^^^^^^^^
White/Red
Page - 45
MSGTOSS Version 2.0
In this case, MSGTOSS is complaining that the actual size of the message
base is 2464, but your RECS:xxx value is set to 500. If you get this er-
ror, fix the appropriate RECS:xxx keyword for these message bases. If the
RECS:xxxx value is correct (what you really want it to be), then execute:
MSGTOSS /SIZE-UP ...... other switches
Then MSGTOSS will size your message bases (using smart-purging) so that
your message bases MATCH the value set for RECS:xxx.
NOTE: This is how easy it is to control the sizes of your message bases (no
more need to use CONFIG!). Simply adjust the appropriate RECS:xxxx
keyword(s), and execute the /SIZE-UP command line switch. For more
information on sizing your message bases, see MSGSWI.DOC (/SIZE
switches) and MSGBBS.DOC (on RECS:xxx).
*************************** IMPORTANT ****************************
* You should run the /TEST until all errors are gone and your *
* FILES=XX in your CONFIG.SYS is corrected and all of your RBBS *
* message-bases are corrected. You can also use the stats infor- *
* mation to determine -RECS:xxxx is correct in your MSGTOSS.BBS *
* file. *
******************************************************************
Page - 46
MSGTOSS Version 2.0
MAIL TOSSING TEST
-----------------
Assuming the /TEST preliminary tests went ok, place a small mail packet
(*.PKT) into your first FILES-------> directory (As listed in your
MSGTOSS.CFG FILE) and test the tossing using....
MSGTOSS /TOSS /PREP <rtn>
Did it work? If it didn't work.... try to determine the part that failed
and go to that step and redo it. Then try again. A good understanding of
how MSGTOSS works should help you understand what may have gone wrong. So
if you can't get it to work correctly, consult the MSGTOSS THEORY section,
along with MSGCFG.DOC, MSGBBS.DOC and MSGSWI.DOC.
MAIL SCANNING TEST
------------------
If everything prior to this has work properly (hallelujah!), then the
scanning test should be a piece of cake. Try entering the following com-
mand at the DOS prompt....
MSGTOSS /SCAN /RBBS /FIDO <rtn>
Did it recognize all of your message bases? It should have, if /TEST
passed ok. See MSGSWI.DOC on /SCAN for more information on this.
You can experiment by entering test messages into RBBS message bases, and
seeing the result. A *.OUT file should have been created in your OUT-
BOUND---> directory to your host for the test message. Now you need to
pack it up.
PACK UP MAIL
------------
For Binkley-type systems, Ommm (version 1.5+ recommended) is normally used
to pack up (and archive) the *.OUT files.
If using Frontdoor, or other types of file-attach mailers, you need to ob-
tain a packer named MAKEARC (other types are available). Its function is
to convert the *.OUT files created by programs like MSGTOSS and create a
file attached message for these files. See example FRONTD.SET for more in-
formation on using Frontdoor and MSGTOSS.
The packer is normally executed after a /SCAN operation.
Page - 47
MSGTOSS Version 2.0
COMMAND LINE SWITCHES
---------------------
MSGTOSS provides alot of command line switches, for each major command line
switch. You may want to experiment using the other common command
line switches, such as /DDA etc.
Read MSGSWI.DOC for the full array of command line switches available. An-
other quick source for command line switches is simply entering at your DOS
prompt:
MSGTOSS <rtn> --or-- MSGHELP <rtn>
Provides a summary of all of the command line switches for all major com-
mand line switches, along with other references, such as a listing of the
MSGTOSS.BBS keywords, errorlevel semaphore files, meta-commands, etc. Use
it for a quick reference, but for more information, consult the appropriate
reference manuals.
1) Toss RBBS, FIDO & NETMAIL messages -------> /TOSS
2) Scan (export) new locally entered mail ---> /SCAN
3) SIZE message bases to preset RECS:xxx ----> /SIZE
4) Reset users Mailwaiting Bit (all msgs) ---> /MWRST
5) Report on message base statistics --------> /STAT
6) Test MsgToss Setup Configuration ---------> /TEST
7) Wait for users, create MSGWAIT.BAT file --> /WAIT
8) Globally execute xxx for all msg bases ---> /GLOB:xxx
9) Recompile the node list (MSGTOSS.NOD) ----> /NLST
10) Execute MSGEID.EXE - EID Database Maint --> /EID
12) MSGTOSS.CMD metacommands - (no slashes) --> xxx
13) MSGTOSS.BBS Tossing Configuring Keywords -> xxx
14) MSGTOSS DOS ErrorLevel Codes -------------> Errorlevels
It is recommended that you re-set all of your mailwaiting bits by issuing
the /MWRST major switch at least weekly during MSGTOSS operation. Try it
right now, as follows (but first read the /MWRST section in MSGSWI.DOC):
MSGTOSS /MWRST <rtn>
Great! Maybe now you can adjust all of the sizes of your RBBS message
bases by issuing:
****** WAIT! ******
Do you throughly understand the purpose of the /SIZE switch(es)? You MUST
make sure all of your RECS:xxxx entries in your MSGTOSS.BBS file correctly
match your RBBS message bases (or you have them set to your wishes). Bet-
ter re-read the /SIZE section of MSGSWI.DOC before issing the following
command.
MSGTOSS /SIZE (or /SIZE-UP)
After you see their power, you will appreciate how easy it is to maintain
tight control of size of your message bases.
Page - 48
MSGTOSS Version 2.0
BATCH FILE MODIFICATION
-----------------------
This assumes that you have decided that MSGTOSS is the greatest RBBS
tossing utility you have ever seen, and are going to commit it to your
system for full-time operation.
Using the following batch file excerpt as a guide, test MSGTOSS to make
sure it works as stated. It is highly recommended that you set up some
sort of 'TEST-JIG' batch file to convince yourself that it works.
Here is an example. Note that this can take on many different forms and
this is just a PORTION of the batch file.
WARNING!: Save your old setup, incase you can't seem to get MSGTOSS to
work properly, its 2:00 am, and you are expecting a 1 meg
packet any minute. In other words, don't shoot yourself in the
foot. REM out your existing batch file commands FIRST, then
when you are satisfied MSGTOSS is working perfect, then remove
the old batch file lines (after a week).
PACKET UNARCHIVING
------------------
SPAZ INFO - Command to issue to unarchived mail packets. Recommended
to use SPAZ.COM, can handle ZIP, LHARC, ARC etc.
SPAZ -F C:\MAIL\FILES C:\MAIL\FILES\
------------- ----------------------------
Incoming Mail Where PKTS go for processing
NOTE!! --> Where trailing back-slashes are!
NOTE: MSGTOSS looks in the directory(s) specified by the FI-
LES------> parameter(s) for PKTs. Therefore, the
C:\MAIL\FILES\ SHOULD match the FILES------> entry.
Page - 49
MSGTOSS Version 2.0
BATCH FILE EXAMPLE
------------------
ECHO OFF
:START
C:
CD\MAILER
Execute Binkley, Frontdoor, whatever..
If errorlevel XX Goto RECMAIL
If errorlevel XX Goto SCAN
If errorlevel XX Goto DAILY
Goto START
:RECMAIL
C:
CD\MSGTOSS
MSGUNPK C:\FILES\ C:\FILES\ (or SPAZ, etc.)
MSGTOSS /TOSS /PREP
If exist C:\FILES\NODEDIFF.A* Goto NODELIST
Goto START
:SCAN
C:
CD\MSGTOSS
MSGTOSS /SCAN /RBBS /FIDO
ommm, makearc, qmail -pack, etc.
REM
REM Ommm for Binkley, Makearc for Frontdoor
REM
Goto START
:NODELIST
C:
CD\NODELIST
SYSNL .... whatever
CD\MSGTOSS \
MSGTOSS /NLST > Added to nodelist processing!
CD\NODELIST /
FINISH ...
Goto START
:DAILY
C:
CD\MSGTOSS
MSGTOSS /SIZE
Goto SCAN
Page - 50
MSGTOSS Version 2.0
HELP!
-----
Help is available in the "RBBS_MSGTOSS" echo (Rbbs-Net) and the "RBBC-PC"
echos (Fidonet & Rbbs-Net). In addition, the following beta testers may be
able to help you as well. Ruediger Fuchs is of special mention, as he is
on the other side of the pond (Europe).
MSGTOSS BETA TESTERS
+--------------------------------------------------------------+
| Jeff Cameron 1:3802/212 The Beanery BBS |
| Jeff Cameron 8:928/105 The Beanery BBS |
| Benny Carr 8:952/25 New Woodstk RBBS |
| Ruediger Fuchs 2:245/32 E.De.Ka.- PC Mail |
| Ruediger Fuchs 8:996/1 E.De.Ka.- PC Mail |
| Craig Gagner 1:3626/1 The TACRBBS |
| Craig Gagner 8:928/102 TACRBBS-PC |
| Bill Hamel 1:273/308 T.T.C RBBS-PC |
| Bill Hamel 8:952/5 T.T.C RBBS-PC |
| Ken Humrich 8:914/701 Nwonknu Hq |
| Tim Jacobs 1:271/271 Virginia Data Exchange 2400 |
| Tim Jacobs 8:935/110 Virginia Data Exchange 2400 |
| Warren King 1:275/429 HandiNet B B S |
| John Kihl 1:129/119 E*COM |
| John Kihl 8:928/104 E*COM |
| Lawrence Kolada 1:327/452 The Plainfield News |
| Lawrence Kolada 8:909/3 The Plainfield News |
| Jan Maaskant 1:387/255 NUL |
| Jan Maaskant 8:931/1 NUL |
| Rick Moen 1:125/27 The Speptic's Board |
| Rick Moen 8:914/207 The Speptic's Board |
| Bob Moravsik 1:2606/583 Atrium Way |
| John Morris 8:919/1 The Abandoned Land I |
| Mark Simmons 1:121/16 Romany RBBS-PC |
| Mark Simmons 8:972/1 Romany RBBS-PC |
| Robert Stahl 1:246/16 Crystal Marine RBBS-PC |
| Robert Stahl 8:952/161 Crystal Marine RBBS-PC |
| Stan Staten 1:109/418 3 WINKs BBS |
| Stan Staten 8:936/105 3 WINKs BBS |
| Ray Waechter 1:273/303 KEYSTONE Net Exchange |
| Ray Waechter 8:952/22 BusiLink (tm) Main Man |
| Michael Walsh 1:273/917 Walsh MicroSystems |
| Michael Walsh 8:952/14 Walsh MicroSystems RBBS-PC |
| Jim Wargula 1:121/8 JW-PC DataFlex.HST |
| Jim Wargula 8:972/2 JW-PC Dataflex |
| Dave West 1:129/201 Info Exchange RBBS-PC #1 |
| Dave West 8:928/301 Info Exchange RBBS-PC #1 |
| Adam Zivitz 1:273/708 Garden of Eden |
+--------------------------------------------------------------+
Page - 51
MSGTOSS Version 2.0
MSGTOSS BETA DISTRIBUTION MATRIX
--------------------------------
A private echo called "MSGBETA" exists on the RBBS-NET backbone where
beta development is discussed and files are distributed. The below
represents the distribution system in-place for beta copies of MSGTOSS.
Note that not all of these systems utilize MSGTOSS.
Mike Zakharoff 1:138/154 (8:918/10)
Warren Muldrow 1:3617/1 (8:928/1) Pvt Nodes
Craig Gagner 1:3626/1 (8:928/102)
+-- Ruediger Fuchs 2:245/32 (8:996/1)
+-- Charles Arden 1:343/81 (8:918/11)
+-- Tyronne Foy 1:264/152 (8:928/103)
+-- Jeff Cameron 1:3802/212
+-- John Kihl 1:129/119
+-- Nathan Barber 1:366/3 (8:925/101)
+-- Bob Dunagan 1:3617/5 (8:928/5)
+-- Ray Waechter 1:273/302 (8:952/1)
+-- Tim Jacobs 8:935/110 (1:271/270)
+-- Bob Moravsik 1:269/583
+-- Stan Staten 1:109/418 (8:936/105)
+-- Larry Kolada 1:327/452 (8:909/3)
+-- Richard Couture 8:914/201 (1:125/41)
| +-- Rod Bowman 8:8/0 (1:10/8)
| | +-- Mark Simmons 8:972/1
| | +-- Jim Wargula 8:972/2 (1:121/8)
| +-- Rick Moen 8:914/207 (1:125/27)
+-- Jan Maaskant 8:931/1 (1:387/255)
+-- Bob Stahl 8:952/16
+-- Michael Walsh 8:952/14 (1:273/917)
+-- Dave West 8:952/12 (1:129/201)
+-- Benny Carr 8:952/25
+-- John Bixler 8:952/15
+-- Bill Hamel 8:952/5
+-- John Morris 8:919/1
+-- Rob Keown 8:952/81 (1:273/718)
Page - 52
MSGTOSS Version 2.0
ERRORS
------
MSGTOSS will (if it encounters a severe error while processing a *.PKT
file) delete the corresponding *.IDX file, and rename the *.PKT to
*.BAD to prevent MSGTOSS from processing it again. You may want to test for
the condition of *.BAD in you batch file to alert you.
In addition, MSGTOSS will (whenever possible) continue on processing
even though it came upon a severe error. MSGTOSS creates a MSGTOSS.ERR
file that contains things it couldn't handle, but processed anyway (or ig-
nored), like trashed message headers, severe errors, etc. Again, you may
want to test for the existence of MSGTOSS.ERR as part of your batch file.
MSGTOSS.ERR should be reviewed periodically.
If you keep extremely large message bases over 4000 (RBBS-MAX * 4) re-
cords, it is possible for your message bases to exceed the RBBS-PC maxi-
mum of 999 (RBBS-MAX) messages per message base. Therefore MSGTOSS will
do a "pre-count" of the messages prior to tossing. This "pre-
count" is automatic and is triggered only when MSGTOSS senses the over
4000 record (RBBS-MAX * 4) message base.
In the event of an "overflow", MSGTOSS will not allow any more messages to
be imported into the message base, but will allow other message bases
to be processed as normal. After the *.PKT is tossed normally, MSGTOSS
will re-name the *.PKT to *.OFL (for overflow) and log the occurrence
of the overflow into the MSGTOSS.LOG and MSGTOSS.ERR files. The sysop
can then elect to fix the overflow problem, or simply delete the *.OFL
file. Tossing of selected echoes are possible via the /AREA: com-
mand line switch(es) (see /AREA: & /AREAF:" switch).
NOTE: It should be noted that the possibility of an overflow is less likely
in MSGTOSS 2.0 vice earlier versions. See SLAK:xxx bbs keyword.
MSGTOSS 2.0 was beta tested to the hilt, almost 2 years! However, there
still is a possibility of receiving a *.PKT file that is beyond the capa-
bility of MSGTOSS to process. If you are a supporter of MSGTOSS, send the
*.PKT to me for analysis and a possible fix. If you are a non-supporter, I
may be interested, but don't expect me to bend over backwards to fix your
problem. Future upgrades and enhancements DEPEND on the amount of support
I receive.
Page - 53
MSGTOSS Version 2.0
PERFORMANCE OPTIMIZATION
------------------------
Here are a few tips to make your mail events as fast as possible.
1) Use a disk cache! Even just a 64K cache makes a BIG difference!
3) Use the SECL:1 keyword. Can ONLY be used with the FMAS:1 switch.
4) Use the /NSTOP and /DDA switches, will also speed up MSGTOSS.
5) Consider NOT using the automatic DUP checker (CDUP:1 keyword). If
your hub faithfully checks for dups then it may not be necessary.
6) Use a RAM DISK with the /WDIR (work directory) command line
switch. The RAM disk is configured by the WORKDIR---> parameter in
the MSGTOSS.CFG file. Will speed up purging, mailwaiting, sizing &
tossing).
7) The Use of a disk de-fragmentor is NOT CRITICAL, as MSGTOSS does
not fragment message bases! Its pack-in-place purging technique pre-
vents this from happening. However, it doesn't hurt.
8) Keep your conference USERS file(s) small (mine have ONLY 32 user
records!) and purge them after so many months of inactivity. If a
user decides to browse the conference but doesn't enter mes-
sages; MSGTOSS will slow down because it will be looking for messages
to/from that inactive user. You can set up a daily MU-PURGE control
file to do this. Here is an example of mine:
users /USR:D365 LOG /10 /25
commu.def /USR:D30 LOG /40 /60
consultu.def /USR:D30 LOG /40 /60
c_prgmu.def /USR:D30 LOG /40 /60
Notice that they get BOOTED out of the conference if they haven't en-
tered it in over 30 days. In addition, once they are purged then
any messages that they left or are waiting will also be purged.
All of my 'U.DEF' files are only 4096 bytes, good for only 32
users (I haven't run out of room yet).
9) Avoid the /FEED switch (unless you feed nodes)
10) Use the MSGTOSS.BBS keyword USRH:0 whenever you have large user bases.
11) You can use the /PREX (pre-expand) option, and chop the message bases
at night using the /SIZE switches.
12) For multi-tasking/networking, use the smallest value of LOCKWAIT--->
you can get away with without affecting your users.
13) Avoid the message "capturing" feature of MSGTOSS 2.0, will slow down
the analyzing phase.
14) Avoid the HIST:x keyword. WIll slow down purging
Page - 54
MSGTOSS Version 2.0
MODIFY RBBSSUB2.BAS TO SUPPORT /MUSER:X
---------------------------------------
The following code provides a means of modifying the WHOSON routine of
RBBS-PC allowing a user to see the last MSGTOSS execution status by
entering the "[W]ho else is on" function on RBBS's main menu, even
though MSGTOSS is actually off-line. During a /TOSS, MSGTOSS will mod-
ify its own node record (as defined by /MUSER:x) as it passes through
its various tossing phases. A user will be able to see it working by
entering [W]ho, but when MSGTOSS goes off-line a user will see "Waiting
for next caller". This modification will allow a user to see the other
node records, including the MSGTOSS node record. For more informa-
tion, see MSGSWI.DOC.
Code segment provided by:
Michael Walsh (NHUB/NC Philadelphia Metro (FidoNet)
Modification for RBBSSUB2.BAS (WHOSON:9801)
SUB WhosOn (NumNodes) STATIC
WasA1$ = ZActiveMessageFile$
ZActiveMessageFile$ = ZOrigMsgFile$
CALL OpenMsg
FIELD 1, 128 AS ZMsgRec$
FOR NodeIndex = 2 TO NumNodes + 1
........
........ code shortened
........
IF MID$(ZMsgRec$,40,2) <> "-1" THEN _
WasAX$ = WasAX$ + ZFG4$ + MID$(ZMsgRec$,93,22)
IF MID$(ZMsgRec$,57,1) = "A" THEN _
ZOutTxt$ = ZOutTxt$ + " Online at " + _
WasAX$ _
ELSE IF NOT ZSysop THEN _ \
ZOutTxt$ = ZOutTxt$ + _ > Delete these!
" Waiting for next caller" _ /
ELSE ZOutTxt$ = ZOutTxt$ + _
" Offline at " + _
WasAX$
CALL QuickTPut1 (ZOutTxt$)
CALL AskMore ("",ZTrue,ZTrue,ZAnsIndex,ZFalse)
IF ZNo THEN _
NodeIndex = NumNodes + 2
NEXT
ZActiveMessageFile$ = WasA1$
CALL QuickTPut (ZEmphasizeOff$,0)
END SUB
What it winds up looking like on a 4 node system running RBBS-PC V17.3C:
Node 1 Offline at 2400 BPS: JOSEPH GARECHT NORRISTOWN, PA
Node 2 Online at 9600 BPS: SYSOP PHILADELPHIA, PA
Node 3 Offline at 300 BPS: MsgToss 2.0 - Mail System Last: 01-18 23:42:31
Node 4 Offline at 300 BPS:
Page - 55
MSGTOSS Version 2.0
EPILOG
------
MSGTOSS took 1000's of hours to develop and test and I believe it to be
one of the finest mail processors in the Fidonet community, and most cer-
tainly for RBBS-PC. If you use this program then please help support
it. Show your support by registering this program. Meanwhile, happy
BBSing! Mike
Page - 56
